Security Audit for Firebase Apps
In a Firebase app, the client talks to Firestore, Realtime Database, and Storage directly. Your Firebase API key is not a secret; your Security Rules are the boundary. AI tools often generate rules that make the app work in development and leave it open in production.
30-minute intro call · fixed-scope quote · human review, not scanner output. Read client case studies.
What we find most often in Firebase apps
Firebase's model is secure when rules are written carefully. Most serious issues trace back to rules written to get past a permission error.
Open or test-mode rules
Rules such as `allow read, write: if true;` or test-mode rules expose your whole database. Test-mode rules also expire, which can break the app suddenly or lead to rushed, wider rules.
Rules that only check login
`if request.auth != null` lets any signed-in user read or write every document. Rules need to check that the document belongs to the requesting user or their team.
Client-writable roles and prices
If users can write fields such as `role`, `isAdmin`, `credits`, or `price` on their own documents, they can grant themselves access. Rules must restrict which fields each user can change.
Storage rules left broad
Cloud Storage rules are separate from database rules and are often forgotten, exposing uploaded files to any user or to the public.
Cloud Functions without auth
HTTP and callable functions that use the Admin SDK bypass Security Rules. They must verify the caller and check ownership before reading or writing data.
No App Check or abuse limits
Without App Check and quotas, scripts can call your backend directly, run up bills, scrape data, or abuse sign-up and AI-powered functions.
What a Firebase security audit covers
A fixed-scope review of your Firebase project configuration, rules, and functions, plus the client code that uses them.
Checks you can run yourself
Start here before you book anything. If any of these fail or you are not sure how to check, that is the signal to get a second pair of eyes.
- Search your rules files for `if true` and test-mode expiry dates.
- Confirm each collection's rules compare `request.auth.uid` with the document's owner, not just that a user is signed in.
- Check that users cannot write role, credit, or price fields on their own documents.
- Review your Storage rules separately from your database rules.
- Use the Rules Playground to simulate a request from a second user against another user's data.
Want a scored version? Take the free vibe code security check or work through the 25-point launch checklist.