Firebase exposes private Firestore documents

1. Match the live configuration.

   Open the app’s Firebase initialization code and read projectId in its web config. Compare it with the intended Firebase console project. Do not judge access by whether apiKey is visible; Firebase web configuration is intended to be present in client code.

2. Inspect the published rules.

   In Firebase console, select the project, open Cloud Firestore and choose Rules. Find the match block covering the disposable document’s path. Read its allow read condition, including any broader match blocks that also permit access.

3. Simulate the ownership boundary.

   Open Rules Playground in the rules editor. Select a read at the disposable document path with the owner’s user id, then run the same read with the unrelated test account’s id. Record the allowed or denied result for each, and also check an unauthenticated read.

4. Compare the version-controlled source.

   Open firebase.json in the app’s repository and locate the configured Firestore rules file, often firestore.rules. Read that file and compare it with the console rules. Record a mismatch before publishing anything; a later CLI deployment can overwrite console edits.

WORKSThe owner’s read is allowed while the unrelated and unauthenticated reads are denied.

BROKENThe matching rules grant a read outside the intended ownership or membership boundary.

Ranked in the order to investigate, not by claimed frequency.

1. The rules permit any reader or any signed-in account.

   Write the intended ownership or membership condition for this document path and test both allowed and denied users. Do not use an allow-all rule to make an error disappear. Publish only after the checks match the intended access.

2. The repository deploys an older rules file.

   Update the configured rules source and use the project’s reviewed deployment process. Reopen the console afterward to confirm the rule version actually applied to the intended database.

3. The app initializes a different Firebase project.

   Correct the web config to the intended project and rebuild the app. Review that project’s rules too; fixing the project id does not prove its document permissions are appropriate.

• Server libraries bypass Firestore Security Rules and rely on other authorization, including IAM. A backend that returns private documents needs a separate review even if client rules pass.
• The Rules Playground is a focused simulation. Repeat the read through real test accounts after deployment, and use emulator tests for broader rule coverage.

When to stop and hand it over

Stop if the unrelated identity is allowed, if the source of deployed rules is unclear, or if the app uses a privileged server route. Provide the project id, harmless document path and the three simulation outcomes. Do not share private document contents.