I worked at Firebase for many years and the concerns with security rules have always plagued the product. We tried a lot of approaches (self expiring default rules, more education, etc) but at the end of the day we still see a lot of insecure databases.
I think the reasons for this are complex.
First, security rules as implemented by Firebase are still a novel concept. A new dev joining a team adding data into an existing location probably won’t go back and fix rules to reflect that the privacy requirements of that data has changed.
Second, without the security of obscurity created by random in-house implementations of backends, scanning en masse becomes easier.
Finally, security rules are just hard. Especially for realtime database, they are hard to write and don’t scale well. This comes up a lot less than you’d think though, as any time automated scanning is used it’s just looking for open data, anything beyond “read write true” as we called it would have prevented this.
Technically there is nothing wrong with the Firebase approach but because it is one of the only backends which use this model (one based around stored data and security rules), it opens itself up to misunderstanding, improper use, and issues like this.
To be honest I've always found the model of a frontend being able to write data into a database highly suspect, even with security rules.
Unlike a backend where where the rules for validation and security are visible and part of the specifications, Firebase's security rules is something one can easily forget as it's a separate process, and has to be reevaluated as part of every new feature developed.
We tried to contact google, via support to try to help or for them to help disclose the issues to the websites. We got no response other then a response telling us that they will be creating a feature request on our behalf if we wanted instead of helping us, which is fair as I think we'd have to escalate pretty far up in Firebase to get the attention of someone who could alert project owners.
Looking at https://firebase.google.com/docs/rules/basics, would it be practical to have a "simple security mode" where you can only select from preset security rule templates? (like "Content-owner only" access or "Attribute-based and Role-based" access from the article) Do most apps need really custom rules or they tend to follow similar patterns that would be covered by templates?
A big problem with writing security rules is that almost any mistake is going to be a security problem so you really don't want to touch it if you don't have to. It's also really obvious when the security rules are locked down too much because your app won't function, but really non-obvious when the security rules are too open unless you probe for too much access.
Related idea: force the dev to write test case examples for each security rule where the security rule will deny access.
One simple trick helped us a lot: we have a rules transpiler (fireplan) that adds a default "$other": {".read": false, ".write": false} rule to _every_ property. This makes it so that any new fields must be added explicitly, making it all but impossible to unknowingly "inherit" an existing rule for new values. (If you do need a more permissive schema in some places you can override this, of course.)
Our use of Firebase dates back 10+ years so maybe the modern rules tools also do this, I don't know.
What would really help us, though, would be:
1. Built-in support for renaming fields / restructuring data in the face of a range of client versions over which we have little control. As it is, it's really hard to make any non-backwards-compatible changes to the schema.
2. Some way to write lightweight tests for the rules that avoids bringing up a database (emulated or otherwise).
3. Better debugging information when rules fail in production. IMHO every failure should be logged along with _all_ the values accessed by the rule, otherwise it's very hard to debug transient failures caused by changing data.
I've been an advocate for Firebase and Firestore for a while — but will agree to all of these points above.
It's a conceptual model that is not sufficiently explained. How we talk about it on own projects is that each collection should have a conceptual security profile, i.e. is it public, user data, public-but-auth-only, admin-only, etc. and then use the security rule functions to enforce these categories — instead of writing a bespoke set of conditions for each collection.
Thinking about security per-collection instead of per-field mitigates mixing security intent on a single document. If the collection is public, it should not contain any fields that are not public, etc. Firestore triggers can help replicate data as needed from sensitive contexts to public contexts (but never back.)
The problem with this approach is that we need to document the intent of the rules outside of the rules themselves, which makes it easy to incorrectly apply the rules. In the past, writing tests was also a pain — but that has improved a lot.
It's not that difficult to build the scanner into the firebase dashboard. Ask the developer to provide their website address, do a basic scanning to find the common vulnerability cases, and warn them.
It also makes portability a pain. Switching from an app with Firebase calls littered through the frontend and data consistency issues to something like Postgres is a lengthy process.
Firebase attracts teams that don’t have the experience to stand up a traditional database - which at this point is a much lower bar thanks to tools like RDS. That is a giant strobing red light of a warning for what security expectations should be for the average setup. No matter what genius features the Firebase team may create this was always going to be a support and education battle that Google wasn’t going to fully commit to
at Steelhead we use RLS (row level security) to secure multi-tenant Postgres DB. Coolest check we do is create a new Tenant and dbdump with RLS enabled and ensure the dump is empty. Validates all security policies in 1 fell swoop.
The security rules where I fell off my love with Firebase, not that there is anything wrong with the security, but until the point of having to write those security rules, the product experience felt magical, so easy to use, only one app to maintain pretty much.
But with the firebase security rules, I now pretty much have half of a server implemented to get the rules working properly, especially for more complex lookups. And for those rules, the tooling simply wasn't as great as using typescript or the likes.
I haven't used firebase in years tho, so I don't know if it has gotten easier.
Firebase needs something like RLS (row-level security). It needs to be real easy to write authorization rules in the database, in SQL (or similar), if you're going to have apps that directly access the database instead of accessing it via a proxy that implements authorization rules.
I view the issue as more of a poor UX choice than anything else. Firebase's interface consists entirely of user-friendly sliders and toggles EXCEPT for the security rules, which is just a flimsy config file. I can understand why newer devs might avoid editing the rules as much as possible and set the bare minimum required to make warnings go away, regardless of whether they're actually secure or not.
There should be a more graphical and user-friendly way to set security rules, and devs should be REQUIRED to recheck and confirm them before any other changes can be applied.
Many businesses don’t have full time developers. They contract out to agencies who build the website for them. The agencies have a rotating cast of developers and after the initial encounter with their good devs they try to rotate the least experienced developers into handling the contract (unless the company complains, which many don’t).
The vulnerability emails probably got dismissed as spam, or forwarded on and ignored, or they’re caught in some PM’s queue of things to schedule meetings about with the client so they can bill as much as possible to fix it.
> Some days I think one ought to be licensed to touch a computer.
There are plenty of examples of fields where professional licensing is mandatory but you can still find large numbers of incompetent licensed people anyway. Medical doctors have massive education and licensing requirements, but there is no shortage of quack doctors and licensed alternative medicine practitioners anyway.
Sadly, this is true, and theres probably much more. We did our best, sent customized emails to each of them, telling what was affected, how to fix it, and how to get in contact.
This is the inevitable outcome of picking cheap-fast from the cheap-fast-good PM triangle. Unfortunately for some customers/users, their concerns were left out of the conversation and their PII is the cost.
I’d be wary of any company listed here that made that decision and hasn’t changed leadership, as it has been proven time and time again that many companies simply don’t care enough about customers enough to protect them. History repeats itself.
I have a very basic Firebase question: are most of the apps described in this post implemented entirely as statically hosted client-side JavaScript with no custom server-side code at all - the backend is 100% a hosted-by-Google Firebase configuration?
If so, I hadn't realized how common that architecture had become for sites with millions of users.
Yeah. Either entirely client-side or passing through a server naively. This is the inevitable result of having an "allow by default" security model in an API. Unfortunately, insecure defaults are a common theme with libraries targeted at JavaScript developers. GraphQL is another area I would expect to see these kinds of issues.
Somehow my assumption is it will only get worse from here, with AI agents looking for exploits etc with much more efficiently than bots? weird future is waiting
It’s not enough; make sure to use a unique email for each service you sign up for. This limits the damage in case of an incident and protects your privacy, as no one can perform OSINT on you to cross reference other services. Additionally, I’ve found that sometimes you can detect a site breach before the owners do when you receive a malicious email sent to that unique address.
> Turns out that a Python program with ~500 threads will start to chew up memory over time.
Anyone have more info about this issue? I've got a scraper myself in Python with a few hundred threads which seems to eat a lot of memory. Any workarounds or is the only solution to rewrite in another language?
I’d be interested to know how you’re coming to the conclusion that the amount of affected users is likely higher. From the looks of it, I’d suspect that at least some of the sites you mention (gambling, lead carrot) to be littered with fake account data.
That customer support looked like an automated AI response..
But I’m not surprised of the scale, years ago same thing happened with AWS cloud XY service, and you would find the token literally in plaintext in millions of smartphones apps.
Definitely. They even let you export the password hashes (which you should do carefully). You can then import them into any identity provider that supports modified scrypt[0]. Your users will continue to be able to log in without a password reset.
We only scanned for firestore, which is a NoSQL database, conversion tools may still be possible, a good firebase alternative would be https://supabase.com, but please set up RLS, its IMO much easier then Firebase.
Because writing the boilerplate that hooks up the DB to an ORM Model to a ViewModel to a Router and then back via a Controller to the Model to the DB again sucks? A lot of the times it's equivalent to writing manual getters and setters except it's many many lines of code over many files... No wonder people are trying to cut corners!
[+] [-] abeisgreat|2 years ago|reply
I think the reasons for this are complex.
First, security rules as implemented by Firebase are still a novel concept. A new dev joining a team adding data into an existing location probably won’t go back and fix rules to reflect that the privacy requirements of that data has changed.
Second, without the security of obscurity created by random in-house implementations of backends, scanning en masse becomes easier.
Finally, security rules are just hard. Especially for realtime database, they are hard to write and don’t scale well. This comes up a lot less than you’d think though, as any time automated scanning is used it’s just looking for open data, anything beyond “read write true” as we called it would have prevented this.
Technically there is nothing wrong with the Firebase approach but because it is one of the only backends which use this model (one based around stored data and security rules), it opens itself up to misunderstanding, improper use, and issues like this.
[+] [-] supriyo-biswas|2 years ago|reply
Unlike a backend where where the rules for validation and security are visible and part of the specifications, Firebase's security rules is something one can easily forget as it's a separate process, and has to be reevaluated as part of every new feature developed.
[+] [-] xyzeva|2 years ago|reply
[+] [-] seanwilson|2 years ago|reply
A big problem with writing security rules is that almost any mistake is going to be a security problem so you really don't want to touch it if you don't have to. It's also really obvious when the security rules are locked down too much because your app won't function, but really non-obvious when the security rules are too open unless you probe for too much access.
Related idea: force the dev to write test case examples for each security rule where the security rule will deny access.
[+] [-] piotrkaminski|2 years ago|reply
Our use of Firebase dates back 10+ years so maybe the modern rules tools also do this, I don't know.
What would really help us, though, would be:
1. Built-in support for renaming fields / restructuring data in the face of a range of client versions over which we have little control. As it is, it's really hard to make any non-backwards-compatible changes to the schema.
2. Some way to write lightweight tests for the rules that avoids bringing up a database (emulated or otherwise).
3. Better debugging information when rules fail in production. IMHO every failure should be logged along with _all_ the values accessed by the rule, otherwise it's very hard to debug transient failures caused by changing data.
[+] [-] nness|2 years ago|reply
It's a conceptual model that is not sufficiently explained. How we talk about it on own projects is that each collection should have a conceptual security profile, i.e. is it public, user data, public-but-auth-only, admin-only, etc. and then use the security rule functions to enforce these categories — instead of writing a bespoke set of conditions for each collection.
Thinking about security per-collection instead of per-field mitigates mixing security intent on a single document. If the collection is public, it should not contain any fields that are not public, etc. Firestore triggers can help replicate data as needed from sensitive contexts to public contexts (but never back.)
The problem with this approach is that we need to document the intent of the rules outside of the rules themselves, which makes it easy to incorrectly apply the rules. In the past, writing tests was also a pain — but that has improved a lot.
[+] [-] mh8h|2 years ago|reply
[+] [-] andenacitelli|2 years ago|reply
[+] [-] ben_jones|2 years ago|reply
[+] [-] markhalonen|2 years ago|reply
[+] [-] kjuulh|2 years ago|reply
But with the firebase security rules, I now pretty much have half of a server implemented to get the rules working properly, especially for more complex lookups. And for those rules, the tooling simply wasn't as great as using typescript or the likes.
I haven't used firebase in years tho, so I don't know if it has gotten easier.
[+] [-] cryptonector|2 years ago|reply
[+] [-] mistrial9|2 years ago|reply
[+] [-] Logykk|2 years ago|reply
[+] [-] begueradj|2 years ago|reply
HN: https://news.ycombinator.com/item?id=38933999
[+] [-] rjbwork|2 years ago|reply
Insane.
Some days I think one ought to be licensed to touch a computer.
[+] [-] Aurornis|2 years ago|reply
The vulnerability emails probably got dismissed as spam, or forwarded on and ignored, or they’re caught in some PM’s queue of things to schedule meetings about with the client so they can bill as much as possible to fix it.
> Some days I think one ought to be licensed to touch a computer.
There are plenty of examples of fields where professional licensing is mandatory but you can still find large numbers of incompetent licensed people anyway. Medical doctors have massive education and licensing requirements, but there is no shortage of quack doctors and licensed alternative medicine practitioners anyway.
[+] [-] xyzeva|2 years ago|reply
[+] [-] MrBruh|2 years ago|reply
[+] [-] bsder|2 years ago|reply
[+] [-] itqwertz|2 years ago|reply
I’d be wary of any company listed here that made that decision and hasn’t changed leadership, as it has been proven time and time again that many companies simply don’t care enough about customers enough to protect them. History repeats itself.
[+] [-] xyzeva|2 years ago|reply
[+] [-] simonw|2 years ago|reply
If so, I hadn't realized how common that architecture had become for sites with millions of users.
[+] [-] evantbyrne|2 years ago|reply
[+] [-] hazelnut|2 years ago|reply
Could be a mix. Firebase also offers Firebase Functions which are callable functions in the cloud. That code is not public.
However, Firestore or Firebase realtime database both require the user to setup security rules. Otherwise all data can be read by anybody.
[+] [-] cryptonector|2 years ago|reply
Writing appropriate authz rules on the backend has to be made easy.
[+] [-] johnnyAghands|2 years ago|reply
[+] [-] voidUpdate|2 years ago|reply
[+] [-] HaZeust|2 years ago|reply
[+] [-] MrBruh|2 years ago|reply
[+] [-] rfl890|2 years ago|reply
[+] [-] maipen|2 years ago|reply
Still this makes the interent scarier. Most people don't have a clue how fragile the web is and how vunerable they are.
[+] [-] user90131313|2 years ago|reply
[+] [-] xyzeva|2 years ago|reply
Services as time goes on makes making websites easier, and abstracts more stuff, which makes devs oblivious to what they have to configure.
[+] [-] tamimio|2 years ago|reply
It’s not enough; make sure to use a unique email for each service you sign up for. This limits the damage in case of an incident and protects your privacy, as no one can perform OSINT on you to cross reference other services. Additionally, I’ve found that sometimes you can detect a site breach before the owners do when you receive a malicious email sent to that unique address.
[+] [-] suddenclarity|2 years ago|reply
Anyone have more info about this issue? I've got a scraper myself in Python with a few hundred threads which seems to eat a lot of memory. Any workarounds or is the only solution to rewrite in another language?
[+] [-] _tk_|2 years ago|reply
I’d be interested to know how you’re coming to the conclusion that the amount of affected users is likely higher. From the looks of it, I’d suspect that at least some of the sites you mention (gambling, lead carrot) to be littered with fake account data.
[+] [-] tamimio|2 years ago|reply
[+] [-] hubraumhugo|2 years ago|reply
[+] [-] ddtaylor|2 years ago|reply
[+] [-] lawgimenez|2 years ago|reply
[+] [-] mooreds|2 years ago|reply
0: https://firebase.google.com/docs/reference/admin/java/refere...
[+] [-] xyzeva|2 years ago|reply
We only scanned for firestore, which is a NoSQL database, conversion tools may still be possible, a good firebase alternative would be https://supabase.com, but please set up RLS, its IMO much easier then Firebase.
[+] [-] dazh|2 years ago|reply
[+] [-] andersa|2 years ago|reply
[+] [-] bruce343434|2 years ago|reply
[+] [-] pizzafeelsright|2 years ago|reply
And we're still in the Wild West when it comes to internet business even after 20 years of "verified" domains.
[+] [-] cozzyd|2 years ago|reply
[+] [-] joshxyz|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]