Firebase security rules checklist for AI-built apps

Firebase lets your app read and write the database straight from the browser. That's convenient, and it means security rules are the only thing deciding who can see and change your data. The Firebase config in your frontend is public by design. The rules are what keep it safe.

AI builders tend to write rules that make the app work, then move on. This checklist covers Firestore and Cloud Storage, and each item can be checked in the Firebase console in a few minutes.

1. No test mode leftovers

Projects started in test mode get rules that allow all reads and writes until a date a few weeks out. When that date passes, the app breaks, and the quick fix is often to remove the date or replace everything with a blanket allow. Search your rules for any of these:

allow read, write: if true;
allow read, write: if request.time < timestamp.date(2026, 11, 1);
allow read, write: if request.auth != null;

The first two let anyone on the internet read and overwrite your data. The third looks safer but isn't much better: anyone can create an account in seconds, and then every signed-in user can read every other user's documents.

2. Owner checks on every user-owned collection

For data that belongs to one user, the rule should compare the signed-in user's ID to the document's owner. Store the owner ID either in the document path or in a field.

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

If the owner is a field instead, check resource.data.ownerId for reads, updates and deletes, and request.resource.data.ownerId for creates. Without the create check, a user can write documents that claim to belong to someone else.

3. Validate what gets written

Rules can do more than allow or deny. They can check the shape of incoming data, which matters because anyone can call Firestore directly and skip your form validation.

• Limit which fields can be set, using request.resource.data.keys().hasOnly([...]).
• Check types and sizes, for example that a title is a string under a reasonable length.
• Block changes to fields users should never edit, like ownerId, createdAt, plan or credits.
• Use request.resource.data.diff(resource.data).affectedKeys() to control exactly which fields an update may touch.

That last point is easy to miss. If a user document holds both a display name and a subscription plan, a rule that lets users update their own document lets them upgrade themselves for free.

4. Admin roles that users can't grant themselves

Checking a role field in a document the user can edit is the Firebase version of trusting the client. Better options:

• Custom claims set from a trusted server with the Admin SDK, then checked in rules with request.auth.token.admin == true.
• A separate roles collection that no client rule allows writing to, read in rules with get().
• Admin-only actions moved into Cloud Functions, which run with admin privileges and can check permissions in code.

Remember that the Admin SDK bypasses security rules entirely. It must only run on servers, and its service account key must never ship in client code.

5. Cloud Storage has its own rules

Storage rules are separate from Firestore rules and are often forgotten. Open the Storage rules tab and check the same things.

1. No allow read, write: if true or bare request.auth != null on paths that hold private files.
2. User uploads stored under a path containing the user ID, with a rule matching request.auth.uid to that segment.
3. Upload size limited with request.resource.size, so nobody fills your bucket with huge files.
4. Content type checked with request.resource.contentType, for example allowing only images for avatars.
5. Public files, like marketing images, kept in their own clearly named path rather than mixed with user data.

6. Test rules before you trust them

Rules are code, and they deserve tests. Firebase gives you two ways to check them without touching production data.

• The Rules Playground in the console simulates a read or write as a specific user and shows which rule allowed or denied it.
• The Firebase Local Emulator Suite runs Firestore and Storage locally, so you can write automated tests with the @firebase/rules-unit-testing library.
• A manual stranger test: sign in as a second account and try to read or edit the first account's data from the browser console.

Write at least one test per collection that proves a stranger is denied. That one test catches most of the mistakes on this list.

7. Extra layers worth turning on

• App Check, which helps make sure requests come from your real app and not a script using your config.
• Budget alerts in Google Cloud, so a runaway read loop or abuse shows up as an email, not a surprise bill.
• Email enumeration protection and sensible sign-up settings in Firebase Authentication.

Deeraf reviews Firebase projects the same way we audit Supabase: every collection and bucket, tested as a stranger, with each finding rated by severity. A Tech Check is the quickest way to know where you stand.