Firebase security rules for vibe-coded apps

Test mode is not a starting point you can leave

Firebase offers a test mode that allows all reads and writes for a short window. It exists so a first prototype works, and it is meant to be replaced. Plenty of apps go live with it, or with the equally open default, because nothing breaks and no warning appears.

• Check the current rules on every project, including the ones you forgot about.
• Treat an open rule as a leak, not a shortcut.
• A project with authentication enabled and open rules is a public database with a login screen in front of it.

Rules are authorization, not filtering

Security rules decide whether a request is allowed. They are not a filter that removes rows after the fact. A rule that lets a request through has already decided it is fine, so the rule must describe exactly who may do what.

• Write rules per collection and per operation.
• Check the authenticated user's id against the document, not against a value the client sends.
• A rule is evaluated on its own for every read and write, so it must be correct in isolation.

Common rule mistakes

• Allowing read to any signed-in user, which lets every account read every record.
• Trusting a role or an owner field that the client is allowed to set during a write.
• Writing a rule on the parent path while a subcollection is left open.
• Forgetting that a custom claim can be stale until the token refreshes.
• Editing rules in the console and never deploying them, or deploying production from a different project than the one you edited.

Auth and App Check

• Email verification where accounts matter, and only the providers you actually intend to support.
• Custom claims for roles, set on the server, never from the client.
• App Check to reduce abuse from outside your own apps, understanding that it is a barrier, not a proof.
• Consider disabling client-side signup if accounts are meant to be created another way.

Storage and functions

• Storage rules are separate from database rules. Check both.
• Do not allow writes to paths that hold another user's files.
• Cloud Functions run with admin privileges, so validate their input as carefully as a public API.
• Anything callable by the client is public, whatever its name suggests.

A Firebase pre-launch pass

1. 01

   Read the deployed rules

   Confirm what is actually live, not what is in your head, and check every project.

2. 02

   Read a document as a stranger

   With no session, try to read a private collection. It should be refused.

3. 03

   Read another user's document

   Signed in as one user, attempt to read a document belonging to another.

4. 04

   Try to write

   Attempt to create or change a record you do not own. Ownership fields must not be settable by the client.

5. 05

   Check the storage rules

   Try to download a file you do not own.

6. 06

   Run an external review

   The running app exposes behaviour the rules file alone cannot show you, from headers to placeholder copy to reachable endpoints.