Firebase
What a Firebase scan can and cannot see
Firebase web apps include an apiKey in the client config. That key identifies the project. It is not a secret by itself, and this scan treats a web config as a note.
Security rules are the actual control. This scan does not download Firestore rules, Realtime Database rules, or Storage rules, and it does not try anonymous reads against your project. That check is shown as coming soon.
What this scan actually checks
- A Firebase web config object in the public HTML or a same-origin script.
- A Google API key string in those same files.
- Other secrets in the same files, such as Stripe or OpenAI keys, plus headers, cookies, exposed env files, and git metadata.
What it does not check
- Rules are not fetched. A quiet scan does not mean your database rejects anonymous reads.
- We do not sign in with Firebase Auth or call Firestore.
- Third-party scripts hosted on other domains are skipped.
What to do with the result
- In the Firebase console, read the rules for each database and bucket you use. Private data should deny access unless the user is the one you expect.
- If a different secret, such as a service account private key, is in the client bundle, that one is a real leak. The report separates it from the web apiKey.
Questions
Should I hide the Firebase apiKey?
No. The web apiKey is designed to be in the app. Hiding it does not secure the data. Rules do.
Where do I see that rules were not tested?
Every report includes a locked section that names Firebase security rules and says they are not run on this scan.
Scan a URL you own
The same free check as the homepage. You confirm the app is yours before it runs.