Keep App Check separate from user identity
A request can contain both a user-authentication token and an App Check token. They answer different questions. The first identifies the authenticated principal; the second contributes evidence about the calling app environment.
The custom backend guide describes token verification. Resource ownership, roles and business authorization still need explicit checks.
Define the server decision order
A robust handler should validate the request shape, verify required credentials, check authorization, enforce relevant abuse controls and only then perform the protected action. Do not trust a client-provided app ID or decoded token payload without verification.
| Input | Server responsibility |
|---|---|
| App Check header | Verify token and expected app/project context |
| User token | Verify authentication under the correct service |
| Resource ID | Check that this user may access the resource |
| Action data | Validate types, limits and business rules |
Handle missing and invalid tokens deliberately
Return an appropriate error rather than continuing with elevated privileges. Avoid exposing detailed verification internals to an untrusted caller, while keeping useful redacted diagnostics for operations.
Do not log full App Check or authentication tokens. They can be replayable credentials during their validity window.
Consider replay protection where supported
The App Check architecture is not a substitute for transaction-level replay or idempotency controls. For sensitive custom actions, evaluate the documented limited-use/replay-protection options and their SDK support, plus server-side action identifiers.
A valid token does not prove that a transfer, purchase or deletion request has never been submitted before.
Test the enforcement boundary
Send one legitimate request, one with a missing header, one with an invalid token and one authenticated user requesting an unauthorized resource. These cases test different controls.
APKLint can help inspect Firebase configuration, but it cannot verify your custom server middleware. The useful completion evidence is a server-side test matrix showing the intended accept/reject decisions without leaking credentials in the report.
Sources and further reading
Reference review: 22 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
