// Security by tool
Security for apps built with Firebase Studio
Quick answer
On Firebase, the hole is almost always the permissive Security Rule: Firestore or Storage configured to accept read and write from anyone (the famous allow read, write: if true). It is the insecure-by-default config that leaks most. In 2025, an open Storage bucket with no authentication exposed tens of thousands of images, including ID photos, and later more than a million private messages.
If you shipped on Firebase Studio and have user data or uploads, the first review is the rule: who can read and write each Firestore collection and each Storage path.
What tends to break on Firebase
Firebase is powerful, but security lives entirely in the Security Rules, and it is easy to leave them permissive to unblock development and forget to close them before publishing.
| Hole | Why it happens | Impact |
|---|---|---|
| Rule allow if true | Open rule left over from development | Public read/write of the database |
| Storage bucket without auth | Upload path with no access rule | File/document leak |
| Rule without owner check | Access per collection, not per user | User reads another’s data |
| Exposed API key | Firebase config in client (expected) but no rule | Without a rule, the key becomes access |
How RET reviews a Firebase Studio app
RET reads the Firestore and Storage Security Rules collection by collection, path by path: where if true sits, where the owner check (request.auth.uid) is missing, which bucket opens without authentication. And it tests in practice what an unauthenticated request can read or write. Findings ship with reproduction and priority.
To run it yourself, the Promptbook has specific prompts to review Security Rules. Serious signals go to Risk Review.
- Read of the Firestore and Storage Security Rules.
- Unauthenticated request test (what reads/writes?).
- Owner check (request.auth.uid) verification per collection.
You may already be exposed if
Signals that call for a review in a Firebase app:
- Your Security Rules still have some allow read, write: if true.
- You have uploads and never checked the Storage rule.
- Your rules allow by collection without checking the document owner.
- You do not know what a request with no login can read in your Firestore.
Frequently asked questions
Is the Firebase API key in the client a problem?
The Firebase config (including the apiKey) is meant to live in the client, that is expected. The problem is not the key, it is the Security Rules: if they are permissive, the key becomes database access. The real protection is the rule, not hiding the config.
What is the if true rule?
It is the Security Rule that allows read and write from anyone (allow read, write: if true), usually left during development to avoid friction. If it reaches production, the whole database is public. It is the number one hole in Firebase apps.
How do I close it properly?
With a rule that checks authentication and ownership: each document is only read/written by its owner (request.auth.uid). RET’s review maps, collection by collection, what is open and what is missing a check.
Who runs the review at RET?
Gabriel Lima Ferreira, founder and lead pentester, with authorization and a tight scope.