Is your Firebase app secure?

Firebase runs the database, authentication, file storage and hosting on Google's infrastructure, over HTTPS. Firebase Auth handles passwords and sign-in providers for you.

Your web app talks to Firestore, Realtime Database and Storage directly from the browser, using the config object with apiKey, projectId and so on. That config is not a secret, and Firebase's own docs say so. Access to your data is decided by Security Rules, which you write. If the rules let everyone read, anyone with your project ID can read.

• Rules still in test mode. Test mode allows all reads and writes until a date, and then the app stops working, which tempts people to extend the date or replace it with allow read, write: if true.
• Rules that only check request.auth != null. Any signed-in user, including one who just made an account, can then read everyone's data.
• Storage rules that let any user read every uploaded file.
• A service account JSON file (with a private_key field) in the front end or in the hosting folder. That key has admin access to your project and ignores rules.
• The API key left unrestricted in Google Cloud, so it can be used for any API enabled on the project.
• Other secrets, such as a Stripe or OpenAI key, called from the browser instead of from a Cloud Function.

Rules live in firestore.rules, database.rules.json and storage.rules in your project, deployed with the Firebase CLI, or in the Rules tab in the console. Scope each collection to its owner:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId}/{document=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

• API key restrictions: Google Cloud console, APIs and Services, Credentials. Restrict the browser key to the APIs your app uses and to your domains.
• Secrets: Cloud Functions with the key stored in Secret Manager, not in the web app.
• Service accounts: server only. If one was public, delete that key in the console and create a new one.
• Headers on Firebase Hosting: a headers array in the hosting section of firebase.json.

Rewrite my Firestore and Storage security rules so each user can only read and write their own documents and files, keyed by request.auth.uid. Remove any rule that allows all access or only checks that the user is signed in. Move any Stripe, OpenAI or other secret key out of the web app into a Cloud Function that reads it from Secret Manager. Add security headers to firebase.json. Show me the rules before deploying.

1. Open the Rules tab for Firestore, Realtime Database and Storage. No test mode dates and no if true on user data.
2. Test the rules in the Rules Playground or the local emulator, as a signed-out user and as a second user.
3. Restrict the browser API key in Google Cloud to the APIs and domains you use.
4. Search the hosting folder and bundles for private_key, BEGIN PRIVATE KEY and other key prefixes.
5. Move any paid API call into a Cloud Function.
6. Add security headers in firebase.json and redeploy.

You can test your own database the way a stranger would, with no credentials. For Realtime Database, request the root of your database URL (shown at the top of the Data tab; projects outside the US use a firebasedatabase.app address):

curl 'https://YOUR-PROJECT-default-rtdb.firebaseio.com/.json?shallow=true'

A permission denied error is what you want. Data means your rules allow public reads. For Firestore, a GET on https://firestore.googleapis.com/v1/projects/YOUR-PROJECT/databases/(default)/documents/users with no auth should also be refused.

An outside scan checks the site itself. It flags a Google API key in your front end as a reminder to confirm it is restricted (it cannot see the restrictions from outside), finds private keys and other secret keys in your HTML and JavaScript bundles, and checks for public .env and .git files, security headers, cookie flags and CORS. It cannot read your Security Rules, so the tests above are how you check them.