App Check for Abuse Reduction: Attestation Concepts, Enforcement Boundaries, and Why It Is Not Authorization

Learning outcomes

1. The AtlasMart problem: valid credentials do not prove a request came from your app

Security Rules can correctly require Alice’s UID and tenant claim, yet automated abuse can still originate from scripts that obtain valid user credentials or call public Firebase APIs directly. App Check adds a separate assertion about the app/device environment. On Web, a common provider is reCAPTCHA Enterprise; on Apple/Android there are platform attestation providers. When Cloud Firestore App Check enforcement is enabled, requests without a valid App Check token are rejected before they become ordinary accepted product requests.

2. App Check is defense in depth, not authorization

A valid App Check token must never replace request.auth.uid, tenant checks, immutable owner fields, or server IAM. If an attacker controls an authentic app instance or valid device, App Check can succeed while the user is still unauthorized for a target order. Conversely, a legitimate user on an unsupported/misconfigured client can fail App Check even though their Firebase Auth identity is valid. Keep those failure domains separate in UI, telemetry, and incident response.

3. Staged rollout: register → observe → enforce

Firebase recommends registering apps/providers, shipping the App Check-enabled client, reviewing App Check request metrics, and then enabling enforcement when legitimate traffic is sufficiently covered. Cloud Firestore supports App Check enforcement. After enabling enforcement, documentation notes that it can take up to about 15 minutes to take effect. Treat that propagation time as an operational transition, not an instant switch.

4. Web example: reCAPTCHA Enterprise provider

import { initializeApp } from "firebase/app";import {  initializeAppCheck,  ReCaptchaEnterpriseProvider} from "firebase/app-check";import { getFirestore } from "firebase/firestore";const app = initializeApp(firebaseConfig);const appCheck = initializeAppCheck(app, {  provider: new ReCaptchaEnterpriseProvider(RECAPTCHA_ENTERPRISE_SITE_KEY),  isTokenAutoRefreshEnabled: true});const db = getFirestore(app);// Security Rules still authorize Firestore data access.// App Check is an additional accepted-app/device signal.

reCAPTCHA Enterprise assessments have their own quotas/pricing. The Web provider documentation explains that assessment requests above the no-cost quota can be charged, and risk-threshold tuning can affect legitimate users. Do not copy a universal threshold into a course. Measure your own score distribution and abuse tolerance.

5. Debug provider: powerful and dangerous

Localhost and CI typically do not qualify as production-attested environments. Firebase provides a debug provider so a registered debug token can be accepted. That token is effectively a bypass for production attestation and must be treated as a secret: do not commit it, expose it in public CI logs, or ship a debug build. Revoke a compromised debug token.

// DEVELOPMENT/CI ONLY — never commit a real registered debug token.self.FIREBASE_APPCHECK_DEBUG_TOKEN = true;const appCheck = initializeAppCheck(app, {  provider: new ReCaptchaEnterpriseProvider(RECAPTCHA_ENTERPRISE_SITE_KEY),  isTokenAutoRefreshEnabled: true});// Read the generated debug token from the local console and register it// in the Firebase console for the isolated development project.

6. Replay: do not overclaim what App Check solves

Baseline App Check session tokens are reusable until expiration. Firebase has limited-use-token replay protection for selected product/custom-backend scenarios, but current App Check metrics documentation states that standard replay-protection monitoring is available for Firebase AI Logic, while custom-backend replay protection is beta and requires your own monitoring. Do not claim that Cloud Firestore App Check makes every database operation one-time-only. For business actions such as checkout or coupon redemption, keep the idempotency keys and durable workflow state introduced in Chapter 10.

7. Auth claims have their own lifecycle

AtlasMart uses tenantId and role custom claims. Firebase requires custom claims to be set only from a privileged server environment; payload is limited to 1000 bytes and should contain access-control data, not a user profile. A claim change appears when a new ID token is issued—after sign-in/re-authentication, normal refresh after expiration, or explicit getIdToken(true). This means role revocation is not the same mechanism as App Check revocation and should be tested independently.

// Trusted backend:await getAuth().setCustomUserClaims(uid, {  tenantId: "t-acme",  role: "support"});// Existing client session: after backend confirms the role change,// force a fresh ID token if immediate propagation is required.await auth.currentUser.getIdToken(true);

8. Optional isolated-project verification checklist

Use a disposable/staging Firebase project and bounded traffic. Never enable production enforcement as an unreviewed course exercise.

Production judgment

App Check is most valuable when combined with strong Rules, safe claims issuance, bounded queries, IAM-separated server paths, telemetry, and an incident runbook. Monitor legitimate-client adoption before enforcement. Treat provider pricing, token TTL, risk threshold and failure rates as workload-specific parameters. Do not publish “one correct” threshold or infer p95/p99 request latency from the emulator.

Lesson 4 converts the Rules contract into CI so query broadening, forged fields and claim-policy regressions fail before deployment.

Knowledge check

1. What does App Check prove?
2. Should App Check replace Security Rules?
3. Why monitor before enforcing?
4. Can baseline Cloud Firestore App Check be described as exactly-once replay protection?
5. When do changed custom claims reach a client?

Summary

AtlasMart now has a clear layered model: Auth identifies the user, Rules authorize data operations, App Check reduces untrusted-client abuse, and IAM secures trusted server paths. None of these layers is allowed to masquerade as another.

Authoritative references

• Securely query data with Cloud Firestore Security Rules
• Writing conditions for Cloud Firestore Security Rules
• Structuring Cloud Firestore Security Rules
• Control access to specific fields
• Test Cloud Firestore Security Rules with the emulator
• Build unit tests for Firebase Security Rules
• Generate Security Rules test reports
• @firebase/rules-unit-testing reference
• Control access with Firebase Authentication custom claims
• Firebase App Check overview
• Enable App Check enforcement
• Monitor App Check request metrics
• App Check with reCAPTCHA Enterprise on Web
• App Check debug provider for Web
• Security Rules for Enterprise Pipeline operations
• Cloud Firestore client/server library trust boundaries
• Cloud Firestore IAM
• Firebase JavaScript SDK release notes
• Firebase Admin Node.js release notes
• Firebase CLI release notes