Firebase App Check: How to Protect Backend Resources From Unauthorized Clients

Mobile and web applications often rely on Firebase services to store data, authenticate users, upload files, and execute backend operations. These services make application development easier, but exposing a backend endpoint or database does not mean every incoming request comes from the genuine application.

An attacker may create a script that sends requests directly to a Firebase service, automate requests outside the official application, or copy publicly available API configuration from a mobile or web app. If the backend relies only on the presence of an API key or a valid user session, it may not have enough information to distinguish a legitimate application request from an automated or unauthorized client.

Firebase App Check helps address this problem by verifying that requests originate from an application or environment that can satisfy the configured attestation mechanism.

This article explains how Firebase App Check works, how to configure it, how to protect Firebase resources, and what developers should consider before enforcing it in production.

What Is Firebase App Check?

Firebase App Check is a service that helps protect Firebase resources and supported custom backends from unauthorized clients.

It uses an attestation provider to assess whether a request comes from a recognized application or environment. When the request passes validation, the client receives an App Check token. The token is then sent with requests to supported Firebase services or a protected custom backend.

The receiving service validates the token before accepting the request.

App Check is designed to complement Firebase Authentication and security rules. These mechanisms address different security questions.

For example, consider a mobile application that allows authenticated users to upload profile images to Cloud Storage.

Firebase Authentication answers:

"Which user is making this request?"

Cloud Storage security rules answer:

"Is this user permitted to upload this object?"

App Check helps answer:

"Does this request present valid evidence from an application or environment recognized by the configured attestation provider?"

Using these controls together provides stronger protection than relying on any one of them alone.

What App Check Does Not Do

App Check is not a replacement for authentication, authorization, input validation, or abuse monitoring.

A valid App Check token does not automatically prove that a user is trustworthy or that every request is safe. A legitimate application can still contain vulnerabilities, and an attacker may sometimes operate through a genuine application.

Developers should continue to enforce authorization rules, validate input, limit resource consumption, and monitor unusual activity.

How Firebase App Check Works

The basic request flow contains four stages.

The application initializes the App Check SDK.
The configured attestation provider evaluates the application or environment.
The SDK obtains an App Check token after successful attestation.
A supported Firebase service or protected backend validates the token before processing the request.

The exact attestation mechanism depends on the platform and provider.

For example, Android applications can use Play Integrity, while Apple applications can use supported App Attest or DeviceCheck configurations. Web applications can use supported reCAPTCHA providers, depending on the application's requirements and Firebase configuration.

The provider's guarantees and limitations differ. A successful attestation should not be interpreted as an absolute guarantee that the device, application, or user cannot be compromised.

Firebase App Check vs. Firebase Authentication

These two services are often confused because both contribute to application security.

Feature	Firebase App Check	Firebase Authentication
Primary purpose	Helps verify the application or environment making a request	Identifies the user
Typical token	App Check token	Firebase Authentication ID token
Main security question	Does the request satisfy the configured application attestation?	Who is the authenticated user?
User account required	Not necessarily	Usually, depending on the authentication flow
Authorization replacement	No	Authentication alone does not replace authorization rules
Typical use case	Reduce unauthorized client access and automated abuse	Sign-in, user identity, and user-specific access

A production application may require both tokens for different purposes.

For example, a request to update a user's account settings may need a valid Firebase Authentication token, an acceptable App Check token, and server-side authorization confirming that the user can update the requested account.

Set Up Firebase App Check

Before writing application code, configure App Check in the Firebase project.

Step 1: Register the Application

Open the Firebase console and select the project containing the application.

Navigate to App Check and register the relevant application. Choose an attestation provider appropriate for the platform.

The exact configuration depends on whether the application runs on Android, iOS, the web, or another supported environment.

For a production mobile application, use the appropriate platform attestation provider and complete its required setup.

For web applications, configure the supported reCAPTCHA provider according to the application's deployment environment.

Step 2: Configure the Provider

Each provider has its own requirements.

For Android, Play Integrity configuration may require the application to meet the relevant platform and distribution requirements.

For Apple platforms, App Attest or DeviceCheck configuration depends on the target operating system, device capabilities, and application setup.

For web applications, the selected reCAPTCHA provider must be configured correctly for the application's domain and deployment model.

Do not copy provider configuration from another application without verifying that it belongs to the intended project and environment.

Step 3: Initialize the App Check SDK

The SDK initialization process differs by platform. The following example demonstrates the general pattern for a web application using Firebase JavaScript SDK and a supported reCAPTCHA provider.

Install the Firebase package:

npm install firebase

Create a Firebase initialization module:

// firebase.js

import { initializeApp } from "firebase/app";
import {
  initializeAppCheck,
  ReCaptchaV3Provider
} from "firebase/app-check";

const firebaseConfig = {
  apiKey: "YOUR_FIREBASE_API_KEY",
  authDomain: "YOUR_PROJECT.firebaseapp.com",
  projectId: "YOUR_PROJECT_ID",
  appId: "YOUR_APPLICATION_ID"
};

const app = initializeApp(firebaseConfig);

const appCheck = initializeAppCheck(app, {
  provider: new ReCaptchaV3Provider(
    "YOUR_RECAPTCHA_V3_SITE_KEY"
  ),
  isTokenAutoRefreshEnabled: true
});

export { app, appCheck };

Replace the placeholders with the appropriate project and provider configuration.

This example uses reCAPTCHA v3. It is intended for a supported web application configured for that provider; it is not a universal initialization pattern for every platform or reCAPTCHA version.

The initializeAppCheck function configures App Check for the Firebase application. The automatic token refresh option allows the SDK to refresh tokens as needed.

Initialize App Check early in the application's startup process, before making requests to services that require App Check tokens.

Important Configuration Considerations

The Firebase web configuration contains identifiers used to initialize the client SDK. These values are not a substitute for access control.

Do not rely on hiding the Firebase API key or embedding a secret in browser code to protect Firebase resources. Browser-delivered code can be inspected by users.

Use Firebase security rules, App Check, authentication, and server-side validation as appropriate for the resource being protected.

Protect Firebase Services With App Check

Initializing the SDK does not automatically mean every Firebase service in the project is enforcing App Check.

Enforcement must be configured for supported products in the Firebase console. Before enabling enforcement, confirm that legitimate application clients are correctly initialized and obtaining valid tokens.

Commonly protected Firebase resources include supported configurations of Cloud Firestore, Realtime Database, Cloud Storage, and other integrated services.

The available products and configuration options can change, so verify support for the specific service and platform in your project.

Example: Protecting Cloud Firestore

Suppose an application stores user profiles in a Firestore collection called users.

A security rule might restrict users to their own documents:

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null
                         && request.auth.uid == userId;
    }
  }
}

These rules check that the request is authenticated and that the requested document belongs to the authenticated user.

They do not independently enable App Check enforcement. App Check must also be configured and enforced for the relevant Firebase resource.

This distinction matters because an application can have valid App Check tokens while still attempting an unauthorized operation. Security rules must continue to control which documents a user can read or modify.

Protect a Custom Backend With App Check

Some applications use Firebase for authentication but send additional requests to their own backend.

For example, a mobile application might call an API that generates a report, processes a payment request, or triggers an expensive computation.

The backend can validate App Check tokens before processing requests.

For supported custom backend integrations, the client SDK can obtain an App Check token and include it in a request. The backend then verifies the token using the appropriate Firebase Admin SDK or supported verification mechanism.

The following example shows the client-side request pattern:

import { getToken } from "firebase/app-check";
import { appCheck } from "./firebase.js";

async function requestReport() {
  const tokenResult = await getToken(appCheck);

  const response = await fetch("/api/reports", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "X-Firebase-AppCheck": tokenResult.token
    },
    body: JSON.stringify({
      reportType: "monthly"
    })
  });

  if (!response.ok) {
    throw new Error(
      `Report request failed: ${response.status}`
    );
  }

  return response.json();
}

This example obtains a token and sends it in the X-Firebase-AppCheck header. The backend must independently validate that token before trusting the request.

Validate the Token on the Backend

A Node.js backend using the Firebase Admin SDK can verify an App Check token as follows:

import express from "express";
import { getAppCheck } from "firebase-admin/app-check";
import { initializeApp } from "firebase-admin/app";

initializeApp();

const app = express();

app.use(express.json());

async function requireAppCheck(req, res, next) {
  const token = req.header("X-Firebase-AppCheck");

  if (!token) {
    return res.status(401).json({
      error: "Missing App Check token"
    });
  }

  try {
    await getAppCheck().verifyToken(token);
    next();
  } catch (error) {
    return res.status(401).json({
      error: "Invalid App Check token"
    });
  }
}

app.post(
  "/api/reports",
  requireAppCheck,
  async (req, res) => {
    // Validate the request body and authorize the operation.
    // Generate the report only after all checks pass.

    res.json({
      message: "Request accepted"
    });
  }
);

app.listen(3000);

The example illustrates the verification flow. In a production application, configure Firebase Admin SDK credentials and project selection using the deployment environment's recommended identity mechanism.

The middleware validates App Check before the route handler executes. The route must still validate the request body, enforce user authorization where required, and apply rate limits or other abuse controls.

If the endpoint requires a signed-in user, validate the Firebase Authentication ID token separately. An App Check token does not identify the user or grant permission to access a particular resource.

Monitor App Check Before Enforcing It

Enabling enforcement without testing can interrupt legitimate traffic.

An application may have users running older versions, an incorrect provider configuration, or clients that do not initialize App Check correctly. Those clients may begin receiving rejected requests after enforcement is enabled.

A safer rollout uses the following approach:

Register the application and configure its provider.
Integrate the SDK into the application.
Test token generation across supported platforms and environments.
Review App Check metrics and identify legitimate clients that are not sending valid tokens.
Fix integration issues before enabling enforcement.
Enable enforcement for the intended services and monitor failures after deployment.

Where supported, use a debug provider for local development and testing. Debug tokens must be handled carefully and should not be embedded in production builds or distributed publicly.

Monitor request failures after enforcement. An unexpected increase in rejected requests may indicate a client integration issue, a provider configuration problem, or unauthorized activity.

Common Mistakes and Troubleshooting

Problem	Possible cause	Recommended action
Requests fail after enforcement	The client does not initialize App Check correctly	Confirm SDK initialization and token availability
App Check tokens cannot be obtained	Provider configuration is incomplete or incorrect	Verify the provider, project registration, and platform requirements
Custom API returns an unauthorized response	The token is missing, invalid, or expired	Confirm the client sends the token and the backend verifies it correctly
Authenticated users cannot access data	Authentication or security rules reject the request, or App Check enforcement rejects it	Inspect the relevant service's error details and validate both security layers
Local testing fails	The development environment is not configured for the selected provider	Configure an appropriate development workflow and debug provider where supported
Automated requests still reach the backend	App Check is being treated as the only abuse control	Add authentication, authorization, rate limiting, validation, and monitoring

Avoid logging complete App Check tokens unnecessarily. Tokens should be treated as security-sensitive values, and logs should not expose them without a clear operational need.

Best Practices for Production Applications

Combine App Check With Security Rules

Use App Check to help verify the client and security rules to enforce access permissions. A valid token should never be treated as permission to read or modify arbitrary data.

Keep Authentication and Authorization Separate

For user-specific operations, validate the user's identity and confirm that the user is authorized to perform the requested action. App Check does not replace these checks.

Protect Expensive Backend Operations

Endpoints that generate reports, process files, or execute expensive computations should use App Check alongside rate limits, request validation, quotas, and monitoring.

Use Separate Development and Production Configurations

Development environments often need different testing arrangements from production. Keep debug tokens and development-only settings out of production builds.

Plan for Client Updates

Older application versions may not support the App Check integration required by a new enforcement policy. Review supported client versions and monitor failures before tightening enforcement.

Review Provider and Platform Support

Attestation capabilities differ by platform. Select a provider that matches the application's distribution model and security requirements, and test the full flow on the devices and browsers your users actually use.

Advantages and Limitations

Advantages

Helps reduce requests from unauthorized clients that cannot satisfy the configured attestation mechanism.
Integrates with supported Firebase products and custom backend workflows.
Complements Firebase Authentication and security rules.
Can help reduce certain forms of automated abuse against exposed resources.
Provides a consistent approach to client attestation across supported application platforms.

Limitations

Does not guarantee that every request from a genuine application is safe.
Does not replace authentication, authorization, input validation, or rate limiting.
Requires platform-specific configuration and client integration.
Can reject legitimate requests if enforcement is enabled before the application is ready.
Does not prevent every form of abuse, especially when an attacker can operate through a genuine or compromised client.

Conclusion

Firebase App Check adds an important layer of protection for applications that rely on Firebase services or expose custom backend APIs. By requiring valid App Check tokens, developers can make it harder for unauthorized clients to access supported resources through direct or automated requests.

The most effective implementation combines App Check with Firebase Authentication, security rules, backend authorization, input validation, and abuse monitoring. Developers should also test the integration before enabling enforcement and establish a process for investigating rejected requests.

App Check is not a complete security solution on its own, but it is a useful part of a layered approach to protecting application resources.