Audit Firebase Security Rules Separately from APK Configuration

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.

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.