Secure your Firebase app, without being a developer

The apiKey in your Firebase config is public, and Firebase says so itself. What protects your data is your security rules. Here are the six places where they let things through, how to see it yourself, and what Rustine checks for you.

At a glance

1. Rules set to if true

allow read, write: if true opens your database to everyone, for reading and writing. Firebase puts it this way: anyone can overwrite your entire database. It's also what test mode gives you.

Check it yourself

In the Firebase console, open the Rules tab of Firestore, Realtime Database and Storage. Look for if true, and ".read": true or ".write": true. The Rules Playground tells you who can read what.

What Rustine checks

On GitHub, Rustine reads your rules files and spots if true. On your proven site, the full audit sees the effect: a database answering an anonymous visitor.

GitHub code · Solo, ProFull audit · Solo, Pro

Sources: [1]

2. Any signed-in user gets everything

request.auth != null looks careful, but if sign-up is open, anyone creates an account and reads or changes your whole database. Firebase advises against it.

Check it yourself

In your rules, every access should compare request.auth.uid with the data's owner, not just check that a user is signed in.

What Rustine checks

On GitHub, Rustine spots rules that open everything to any signed-in user.

GitHub code · Solo, Pro

Sources: [1]

3. A readable Realtime Database

An open Realtime Database reads in one go from its address: the whole data tree at once.

Check it yourself

In the Realtime Database Rules tab, ".read" must not be true at the root. Grant access branch by branch, to the user it belongs to.

What Rustine checks

After proof and once you confirm the project is yours, the full audit checks whether the database answers an anonymous visitor. It reads only the list of top-level keys, never the data.

Full audit · Solo, Pro

Sources: [1]

4. A Storage anyone can list

If your Storage rules let everyone read, every file your users upload becomes public: photos, documents, exports.

Check it yourself

In the Storage Rules tab, no allow read: if true without a condition on the path or the user.

What Rustine checks

After proof and once the project is confirmed, the full audit asks for a single file name to learn whether the list is open. On GitHub, it also reads your Storage rules.

Full audit · Solo, ProGitHub code · Solo, Pro

Sources: [1]

5. Open Firestore collections

A collection readable without signing in, users or orders for instance, exposes its documents to anyone who knows its name. And that name is often in your JavaScript.

Check it yourself

In the Rules Playground, simulate an unauthenticated read on each of your collections. It must be denied, except for what is truly public.

What Rustine checks

After proof and once the project is confirmed, the full audit tries an anonymous read on the collections named in your code, without fetching the documents' content.

Full audit · Solo, Pro

Sources: [1]

6. The real secret keys

The Firebase key isn't a secret. A service account key, a Stripe key or a Gemini key is. In your app, they can be read.

Check it yourself

In your code, no service account private key and no other service's secret key. They belong on the server, in Cloud Functions for instance.

What Rustine checks

From the free scan, Rustine looks for secret keys (Stripe, OpenAI, Anthropic, private keys…) in your site's JavaScript, and leaves the public Firebase key alone. A Gemini key has the same shape as a Firebase key: check it yourself. On GitHub, it reads all your code and its history.

Free scanGitHub code · Solo, Pro

Sources: [2]

Questions

Sources

1. Firebase, Avoid insecure rules, read on 15/10/2026
2. Firebase, Learn about using and managing API keys for Firebase, read on 15/10/2026