Possibly, if the database was created in test mode and its rules were never tightened. Firebase's own documentation warns that without proper rules, anyone who guesses your project ID can steal, change or delete the data. The API key you can see in your app is not the problem; Firebase keys are designed to be public. The security rules are what protect your data, so that's where to look.
What's the problem
Your app talks to Firebase straight from the browser or phone. That's how Firebase is meant to work, but it means the only thing standing between the internet and your data is a short set of rules, often written once, in a hurry, at the start.
Why it happens
- Test mode is the easy start. When you create a database or storage bucket, Firebase offers to open it to everyone so you can build without friction. Plenty of apps launch like that.
- Rules that check login but not ownership. "Any signed-in user can read and write" sounds safe, but anyone can sign up, and then read everyone's data.
- Storage gets forgotten. The database rules get fixed and the file storage bucket stays open.
- The public key causes false alarms. People see the API key in the app, assume that's the leak, and miss the rules that actually matter.
How to fix it
- Open the Firebase console, go to Firestore, Realtime Database and Storage in turn, and open the Rules tab for each.
- Look for red flags: rules that allow read or write to everyone, rules that only check a date (test mode), or rules that only check the user is signed in.
- Rewrite them around ownership. A user may read and write only their own records, for example by checking the signed-in user's ID against the record's owner field. Shared data gets its own explicit rules.
- Test the rules in the Rules Playground or the local emulator, including as a signed-out user and as a different user.
- Fix Storage the same way.
- If the data was open for a while, check whether it was read or changed, and whether personal information was involved. See do I have to report a data breach.
When to call Preventionlabs
If you have one collection and simple ownership, the steps above will do it. Call us when the data model is tangled, the app was generated by a tool and nobody knows what it reads where, or tightening the rules breaks the app. Access control and data exposure are on the MVP-level protection checklist in every resurrection, tested by trying to read other users' data, then fixed.
Submit your project for a free assessmentFree assessment. $10,000 AUD flat to get it live, only if we take it on and you go ahead.
Sources
- Firebase: Avoid insecure rulesplatform docs
When you create a database instance or Cloud Storage bucket in the Firebase console, you can choose to either deny access to all users (Locked mode) or grant access to all users (Test mode).
- Firebase: Avoid insecure rulesplatform docs
If you're not authenticating users and configuring security rules, then anyone who guesses your project ID can steal, modify, or delete the data.
- Firebase: Learn about and manage API keys for Firebaseplatform docs
If your app's setup follows the above guidelines, then API keys restricted to Firebase services do not need to be treated as secrets, and it's safe to include them in your code or configuration files.