Firebase is convenient because it connects your app to a database with no backend, but that convenience is also the trap: security depends almost entirely on the rules you write. These are the mistakes that come up most.
Leaving the rules in test mode
When you create Firestore or Realtime Database, Firebase offers a test mode that lets anyone read and write for a while. It is handy to start, but many people launch with those rules still in place. The result: anyone can read and modify your whole database from the browser console.
Before launching, change the rules to require authentication and limit each user to their own data.
Confusing the public key with security
The Firebase config you paste in the frontend (apiKey, projectId, etc.) is public by design and is not a secret. That confuses a lot of people: they assume that because it lives in the client, Google protects it. It does not. What protects your data are the security rules, not hiding that key. Assuming otherwise leads to open databases.
Rules that allow reading everything
A rule like allow read: if true leaves your collections open to anyone. The classic mistake is loosening rules until the app stops throwing errors and never tightening them again. Write per-collection rules: check request.auth and compare the user against the document owner.
Sensitive data in readable documents
Even if you require login, review what you store. Emails, admin roles or internal flags in documents any authenticated user can read are still a leak. Separate private data into collections with stricter rules and do not assume nobody will look.
Other keys hidden in the bundle
The Firebase config is public, but it usually travels with other keys that are not: tokens for payment, email or AI services. Those are secret and must not end up in browser JavaScript. AI sometimes embeds them to make something work on the spot.
Scanaris spots what got exposed
Scanaris runs read-only checks against your published site: it looks for keys and secrets exposed in the frontend, reachable sensitive files and weak header settings. It exploits nothing; it only looks at what is already public and warns you. Every finding comes with a prompt to fix it in your AI. Scan your app before someone else does.