Define the authorization matrix
Use the Security Rules documentation for the specific Firebase product. Firestore, Realtime Database and Storage have different rule models and request contexts.
| Actor | Example test |
|---|---|
| Unauthenticated client | Cannot read private records |
| Record owner | Can perform the intended operation |
| Different authenticated user | Cannot access another owner's data |
| Privileged backend | Uses separately controlled server authorization |
Use test data and authorized environments. Do not probe a third party's database merely because a URL is visible in an APK.
Test writes as well as reads
Validate field types, allowed fields, ownership changes and immutable identifiers. A rule allowing a user to edit their own document can still be unsafe if it permits changing an authorization role or owner field.
Check create, update, delete and query behavior separately. A successful single-document read does not establish that every query is safe or permitted.
Keep App Check in its own role
App Check adds app-authenticity protection for supported services; it does not decide which authenticated user owns a document. A valid app token must not grant access to every resource.
Audit administrative paths
Server SDKs and privileged service accounts may follow different authorization paths from client Security Rules. Restrict their credentials and implement server-side checks where required.
Do not include those credentials in the APK or public build artifacts.
Preserve reproducible tests
Maintain emulator or supported automated rule tests for allowed and denied cases, and review them with schema changes. Avoid temporarily publishing permissive production rules as a troubleshooting shortcut.
APKLint's Firebase Config Scanner helps inventory client configuration, not inspect private rules. A defensible finding includes the intended policy, an authorized reproducible test and the specific rule or server control that enforces it.
Define a small private-notes policy
For an illustrative Firestore notes collection, state the intended rule in ordinary language first: a signed-in user can create a note owned by that user, read and edit their own note, and cannot change its owner or add a privileged role field. A different user cannot read, update or delete it. Decide separately whether notes can be listed and which query shape the app uses. This gives the rule tests a concrete policy to enforce.
Create synthetic users Alice and Bob plus an unauthenticated context in the local emulator. Seed a note through the test setup's controlled administrative path, then perform client operations through each context. Firebase's Security Rules testing guide describes the testing libraries and emulator workflow. Do not use administrative access for the client assertions, because that would test a different authorization path.
Test mutations that an ownership-only check can miss
As Alice, attempt a normal title update, an owner change to Bob, a write containing an unexpected role field and a write with the wrong field type. Assert the intended allow or deny outcome for each. As Bob, attempt a direct read and update of Alice's note. As an unauthenticated client, attempt creation. Keep create and update cases distinct because existing-resource data and proposed data have different roles in those decisions.
Run the actual query used by the application rather than assuming rules will filter unauthorized documents from an arbitrary query. Review the specific product's query authorization semantics. A successful single-document read does not prove a collection query is allowed, and a rejected query does not automatically mean ownership checks are wrong.
After a rule change, run the complete saved matrix and retain the rule version with the result. Add regression cases for newly introduced fields and server endpoints. Review privileged server code separately for user authorization and credential scope. App Check can add a supported app-authenticity boundary, but Alice's valid app token still must not grant access to Bob's notes. The audit should connect each intended policy to a reproducible test and a specific enforcing control, rather than infer backend safety from the absence of suspicious strings in an APK.
Sources and further reading
Reference review: 29 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
