Now on AndroidScan free

Your Cloud Firestore database has insecure rules: how to fix it

Short answer: Open Firestore’s Rules tab and replace public or test-mode access with rules matching your app’s users and data. The email points to access rules; hiding the Firebase web API key will not fix them.

Ember can help check what your published app shows a visitor. Run a free SniffPup scan of your own site. Passive checks only; a clean scan is not proof of security.

Home › Guides › Firestore insecure rules · Last updated · By Ember, SniffPup

1. Find the rule that grants public access

allow read, write: if true; lets anyone read and write matching documents. Test-mode request.time < timestamp rules also allow public access until their cutoff. Extending the timestamp extends that exposure. After the cutoff, requests covered only by that rule are denied.

2. Scope private documents to their owner

For private documents under /users/{userId}, require request.auth != null && request.auth.uid == userId. The path userId must represent the owner’s Firebase Authentication UID. Adapt paths to your schema; a parent document rule does not automatically cover subcollections.

3. Remove overlapping broad grants

Remove old allow-all matches, including recursive wildcards. If any matching allow rule grants a request, a stricter rule elsewhere does not cancel it. Add field validation and separate read/write permissions where your app needs them. Admin SDK server access bypasses these client rules and needs its own authorization.

4. Test before publishing

Use Rules Playground in the Firebase console or the Firestore emulator. Check reads and writes signed out, as the document owner, and as a different user. Include create, update, delete and queries used by the app. Publish the tested rules to the correct project and database, then repeat client checks.

5. Review Storage rules too

Cloud Storage has separate rules. Check for allow-all and time-limited test-mode access there too, scope private files to their owner and test downloads and uploads. Firestore rules do not protect Storage objects. Review logs and exposed data if public access was possible.

Example: private user documents

This example covers documents directly under users. Add explicit rules for the other paths your app needs, and remove broad grants before testing.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

See the Firebase test-mode walkthrough and the Firebase security rules checker. An outside site scan cannot review your deployed rule text.

Next: Is the Firebase web API key safe to expose? and Find exposed API keys on your website.

FAQ

Will changing the Firebase API key fix the insecure rules alert?

No. The Firebase web API key identifies the project. Replace the insecure data access rules and test them.

Is extending a test-mode timestamp a fix?

No. It keeps public access open until the new cutoff. Use rules scoped to the user and the data instead.

Sources: Firestore rule conditions, Rules testing and Storage rules, checked November 5, 2026.