Hacker News Reader

Comment by tpetry | Hacker News Reader

There is something i don‘t understand about Firestore: If you use the web client your javascript code is directly communicating with the firestore database, you have no control about some user specific limits. How do you prevent some rogue actor from effectively doing billions of reads or writes. With server side logic you can implement rate limits but not with a fire store web client. The only thing you can do is to limit your monthly budget? So one bad guy can burn all your money for a month without you having any possibility of limiting it?

View on HN

In these kind of systems, your app users also become database users and effectively each visitor gets their own token to access the database.

You then add rules to limit users so they can only read/write their own data. This works fine for many simpler scenarios and avoids the need for a backend completely, with the potential risk for overuse.

If you need more control and protection then you should have a backend layer to get the data server-side.

By "In these kind of systems, your app users also become database users", do you mean by RBAC or some other session-based control on the backend, or does Firestore perform some intelligent user entity resolution I'm missing?

As far as I can tell, any naked frontend-only client serving content without its own access management sounds quite open to a single bad actor spawning a large number of sessions on the same host, and on a small number of distributed hosts, to eat up all available resources. I'm not inclined to ever trust a number of users behaving nicely at n>100 personally.

Given that Firestore appears to advocate "serverless" client-driven applications, unless there's some foolproof DDoS mitigations I'm finding it a hard sell, especially on the whole "if you need more control and protection, do X" argument - you rarely need that until somebody straight-up exploits you, and when you do, you're not going to be particularly sympathetic towards Google's marketing speak.

You can require login for read/write access

I struggled with this. We implemented Firestore (successfully) in a production mobile game for the real-time chat and configuration aspects. The SDK WebSocket implementation for real-time updates was a huge factor here.

At the time we were using the Firestore beta, Security Rules were also very poorly documented with no tooling apart from the editor (beta product - I know, I know).

Ultimately we found several vulnerabilities in our own implementation of Firestore that were difficult or practically impossible to resolve on our end. The workaround was to communicate with Firestore only by using the admin SDK.

I still completely vouch for Firestore and Firebase as a product.

You have control over user specific limits. You can use Firestore Security rules, and if that doesn't do it you can create a service that runs server-side code to do what you want and then have the client hit that service.

> You can use Firestore Security rules

I think the main problem is that they bolted security (access control) on top of their existing system, rather than make it an integral part of the design.

We built it specifically for Cloud Firestore and as an integral part of the system from the beginning. We always like to hear where we can do better to help prioritize the next set of improvements, and would love to know what gives you the impression of being bolted on.

I’m building an app at the moment with Firestore and 99% of it is amazing or better. It’s a really fantastic tool and y’all are enabling people like me who are less adept to make good stuff. So thanks!

Two minor notes (one on security rules):

(1) in the tutorials I’ve seen, the security rules have received little attention and the documentation I’ve read is a bit confusing about the spectrum of possibilities for security rules. Tbh, I’ve punted security rules altogether until I’m closer to “beta ready” as opposed to writing them along the way. I suspect this is bad practice but haven’t found a better way. Much of this is my fault lol.

(2) “presence” systems still require the use of Real-Time DB. +1 feature request to support user connect/disconnect events in Firestore.

firebaser here Completely agreed that we should do a better job in documenting the security rules. They're very powerful, but a huge paradigm shift for most developers, one that is too easily ignored (at your own and your user's peril). We've already released a bunch of improvements on the documentation, and continue to work on adding new documentation, video tutorials, and console improvements. Please keep telling us where we can/should improve security rules further though.

And yes, also agreed on needing a solution for presence system, either in Firestore itself, or separate from it.

That would be a really weird user experience given how long this has been in Beta. Google has had over 1.5 years to get access control right, so I bet (hope) this is not an issue for new users.

Limiting writes would be fairly easy. You could have an onWrite Function trigger[0] that writes activity to a rate limit Firestore document. When new write requests come in, the Firestore rules can read that rate limit docuemnt and decide if the particular write should be allowed or not.

Limiting reads is interesting. I think generally the idea is data is cheap enough that most people don't have to worry about it. If you do you could gate access through an API in a Function.

[0] https://firebase.google.com/docs/functions/firestore-events

[1] https://firebase.google.com/docs/firestore/security/rules-co...

This is a good question. I think a more general feature it's lacking is auditing (as far as I've been able to find), from which you could judge whether a user was abusive and revoke permissions. There's profiling tools, which you may be able to hack together something for auditing if you were so inclined: https://firebase.google.com/docs/database/usage/profile

I assume that there would be some rate limiting and anti-abuse measures here, like most Google products have. It’s a good question though.

How would an automatic system even prevent unwanted deletion of database entries or that users access others' data? Maybe I am lacking imagination but without server-side validation the practical use cases seem very limited.

It has this: https://firebase.google.com/docs/firestore/security/rules-st...

Ah, interesting, so you basically put the server side validation code into the database. And nice, it can even handle authentication.

Cloud firestore supports placing rules on the database to prevent access by users that aren't authorized. You can independently control get, write, update, list, etc. The way the rules work can sometimes be irritating, in particular for list queries, but they do work.

In terms of rate limiting the only one I'm aware of is writes to a single record are rate limited. This impacts normal development when making counters that need to be updated, which leads to an odd "sharded counter" model.

When I last looked at Firebase, it seems like they bake auth into database so in this case a user is limited on what data they can read, like a select where uuid === uuid https://firebase.google.com/docs/database/security/user-secu.... And I assume non-authenticated read requests don't have access to everything...

Think of it as an API layer and database baked into one.

Reply on news.ycombinator.com