Milo Kits
Guide

Firebase security rules mistakes in AI-built apps (and how to fix them)

By Milo Kits · Updated

The most common Firebase mistake in AI-built apps is rules that check whether someone is signed in instead of whether they own the data: allow read, write: if request.auth != null lets any user (including anonymous sign-ins) read and overwrite everyone's documents. The other usual suspects are test-mode rules that stay open until a date, if true, users being able to write their own role field, and open Storage buckets. Your Firebase API key being public is normal. Security rules are what protect the data, so they have to be specific.

Firebase lets the browser talk to your database directly, and its docs are blunt about what that means: "Firebase Security Rules are the only safeguard blocking access for malicious users" (Firebase: Basic security rules). The web apiKey in your config isn't a secret, because it identifies your project rather than authorising access (Firebase: API keys). So everything depends on the rules.

Mistake 1: test-mode rules left in place

When you start a database in test mode, Firebase writes a rule that opens everything until a date about 30 days out. AI tools (and tired humans) often "fix" the expiry warning by pushing the date forward.

// Test mode: anyone can read/write until the date match /{document=**} { allow read, write: if request.time < timestamp.date(2026, 11, 16); }

Until that date, anyone on the internet can read, change and delete all your data. Firebase lists open access as the first insecure pattern to avoid (Firebase: Avoid insecure rules).

Mistake 2: "signed in" instead of "owner"

// "Logged in" is not the same as "allowed" match /{document=**} { allow read, write: if request.auth != null; }

This looks safe but isn't. Anyone can create an account in your app (or sign in anonymously, if that's enabled) and then read every user's documents. Firebase calls this out as "any authenticated user" access in its insecure rules guide.

Mistake 3: users can make themselves admin

If your app stores role: "admin" or plan: "pro" on the user's own document, and the rules let users update their own document freely, a user can just write role: "admin". Lock role fields so clients can't set them, and change roles from a trusted server (Admin SDK or Cloud Functions) or with custom claims.

Mistake 4: Storage and Realtime Database forgotten

Cloud Storage and Realtime Database have separate rules from Firestore. A tight Firestore setup doesn't help if Storage allows public reads of uploaded files, or Realtime Database has ".read": true at the root.

Mistake 5: no validation on writes

Even with ownership checks, rules that don't validate data let users write huge documents, unexpected fields or someone else's ownerId. Check request.resource.data on create and update.

A safer starting point (Firestore)

rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { // Each user can only read and write their own profile match /users/{userId} { allow read: if request.auth != null && request.auth.uid == userId; // Can't set or change their own role allow create: if request.auth != null && request.auth.uid == userId && !('role' in request.resource.data); allow update: if request.auth != null && request.auth.uid == userId && !request.resource.data.diff(resource.data).affectedKeys().hasAny(['role']); } // Documents owned by a user via an ownerId field match /todos/{todoId} { allow read, update, delete: if request.auth != null && resource.data.ownerId == request.auth.uid; allow create: if request.auth != null && request.resource.data.ownerId == request.auth.uid; } // Everything else: denied by default (no rule = no access) } }

Adapt collection and field names to your app, then test with the Rules Playground in the console or the emulator before deploying (Firebase docs).

Realtime Database and Storage: safer starting points

Realtime Database rules are JSON. This example lets each signed-in user read and write only their own node under /users. Everything else stays denied because no rule grants it (Firebase: Realtime Database rules):

{ "rules": { "users": { "$uid": { ".read": "auth != null && auth.uid === $uid", ".write": "auth != null && auth.uid === $uid" } } } }

Cloud Storage rules look like Firestore's. This example keeps each user's uploads private, and limits writes to images under 5 MB so nobody can use your bucket as free file hosting (Firebase: Storage rules):

rules_version = '2'; service firebase.storage { match /b/{bucket}/o { // Each user can read and write files under users/{their uid}/ match /users/{userId}/{allPaths=**} { allow read: if request.auth != null && request.auth.uid == userId; allow write: if request.auth != null && request.auth.uid == userId && request.resource.size < 5 * 1024 * 1024 && request.resource.contentType.matches('image/.*'); } } }

If some files really should be public (for example product images), put them under a separate path with its own read rule, and keep writes restricted.

Copy-paste fix prompts

Rewrite rules around ownership
Review my Firebase security rules for Firestore, Realtime Database and Cloud Storage. Replace any test-mode (request.time <), `if true` or `request.auth != null`-only rules with rules where: 1. Users can only read and write documents they own (match on request.auth.uid against the document ID or an ownerId field). 2. Users can't create or change role, plan, isAdmin or similar fields on their own documents. 3. Creates and updates validate required fields and types. 4. Anything not explicitly allowed is denied. Show me the full new rules files, explain each rule in one line, and give me Rules Playground tests (logged out, user A, user B) to confirm.
Move role changes server-side
My app lets the client write a user's role/plan field. Please move all role and plan changes into a trusted server path (a Cloud Function using the Admin SDK, or custom claims set server-side, e.g. after a verified payment webhook), update the security rules so clients can't modify those fields, and make the frontend read the role from the token claims or a read-only document.

Extra protection worth turning on

FAQ

Is it safe that my Firebase apiKey is visible in my website code?

Yes. The Firebase web API key identifies your project and isn't used to authorise access to your data. Security Rules do that. Do restrict the key to the APIs you need, and don't put billable non-Firebase APIs on it.

Is 'allow read, write: if request.auth != null' secure?

Usually not. It lets any signed-in user, including anyone who just created an account or signed in anonymously, read and change every document. Rules should check that the user owns the specific document, for example request.auth.uid == userId.

My Firebase test mode is expiring. Should I extend the date?

No. Extending the date keeps your whole database open to the internet until then. Replace the test-mode rule with real rules based on ownership, and test them in the Rules Playground or emulator.

Do Firestore rules also protect Cloud Storage?

No. Cloud Storage and Realtime Database each have their own separate security rules. Review all three if your app uses them.

How do I test my Firebase security rules?

Use the Rules Playground in the Firebase console or the local Firebase emulator. Simulate a logged-out visitor, user A and user B, and confirm that each can only do what you intend.

Sources

This guide is general information, not a security audit. Platforms change, so check the linked docs for current details. Spotted something out of date? Email hello@milokits.com.

More guides