I am working on a mobile app, where users have complex profiles and can chat to each other. So right now I am using firebase's onSnapshot() listener in the frontend code to get the real-time data ASAP. I am thinking whether its secure enough? Would it be better to move it to the backend server? Than fetching real-time would be way more complex I guess. Could you tell me what are the dangers of keeping these listeners on frontend? Thank you.

CodePudding user response：

Could you tell me what are the dangers of keeping these listeners on frontend?

The standard way for securing your database (as well as Cloud Storage buckets) is by using Security Rules.

In particular the documentation explains that:

Every database request from a Cloud Firestore mobile/web client library is evaluated against your security rules before reading or writing any data. If the rules deny access to any of the specified document paths, the entire request fails.

This evaluation is totally independent from the way you query the database: Whether you query it via a realtime listener or via a one time fetch (using one of the get() methods) the database request is evaluated against your security rules.

So, in conclusion, if you use Security Rules, there is no "danger" to use some realtime listeners.

I am thinking whether its secure enough? Would it be better to move it to the backend server?

Based on the details you share in your question there is no reason, IMO, to switch to a back-end approach (like using Cloud Functions to read the database). One reason could be that your security logic is too complex to be implemented with the security rules language/model. But note that you can build complex logic in Security Rules, for example by basing them on Custom Claims or other Firestore documents.