Get your Firebase security rules right before customers rely on them.

Common failure modes

These turn up in fast-built apps whatever they were built with, once an app grows faster than anyone reviews it. Most can be fixed where the app is.

1. Rules left as they were in development

   Rules that allow every read and write leave the data open. Rules set to expire on a date lock everyone out when that date passes, often in production.

2. Rules that only check sign-in

   A rule that allows any signed-in user lets every customer read every other customer's data. Rules have to tie each document to the people who may see it.

3. The public key and the real secrets

   The apiKey in the Firebase web config is public by design: it identifies the project, it does not protect it. Real secrets, such as service account keys, must never ship to the browser or sit in a repository.

4. Cloud Functions that trust the caller

   Functions that use the Admin SDK bypass the security rules, so each one has to check who is calling and validate what it is given.

5. Storage rules

   Cloud Storage has its own rules, separate from the database's. Uploaded files need the same care as records.

6. Costs with no ceiling

   A query in a loop, or an open collection being read by someone else, shows up as a bill. Budget alerts and query limits catch it early.

What the audit checks on a Firebase app

The code and product audit reads the code, not only what is visible from outside, and ranks every finding by what it means for the business. On a Firebase app, that includes:

• Firestore, Realtime Database and Cloud Storage rules, checked against who should see what.
• Keys in the shipped bundle: which are public by design, and which must not be there.
• Authentication providers, sign-up and email verification.
• Cloud Functions: who can call them, and what they trust.
• App Check, API key restrictions and budget alerts.
• Environments, deploys and backups.
• Your product and business goals, from an interview, so every finding is ranked by what it means for the business.

Production-ready where you are

The default recommendation is to harden the app on Firebase. Moving to a different backend is recommended only when the audit shows it is worth the cost.

Run the free check on your Firebase app.

It scans what your app already shows the world, such as keys in its JavaScript, its headers, HTTPS and versions, and Aaron reviews the result within two business days. It runs only after you confirm by email and show the app is yours.