问题
I know when querying from Firebase, you should be extra careful on making sure you're reading the data you want to, but aren't front end writes susceptible to malice? For instance, an attacker could populate their age field with a string (or maybe a dict) instead of a number. Let's say I do a giant query on the backend to compute the average age of users on my site. I do a get for each age and forget to force any strings to integers. Doing this compute with a string crashes my app.
Furthermore, someone could attack my site by loading in insane amounts of data. Even if I set up security rules to only allow someone to change their name, they can set the name as a giant dictionary containing a large amount of data.
Wouldn't it be safer to call my backend api from client side code? This api would validate all of the data is what is expected and not full of random dictionaries or invalid data types.
回答1:
With Firebase (both Realtime Database and Cloud Firestore) you'll use server-side security rules to enforce both the format of the data that is written, and ensure that all data access is authorized. For example, you can make sure that a user can only modify their own name and that they can only write a name of a certain length.
Since these rules are enforced on Firebase's servers, there is no way for client-side code to bypass them. In that sense they secure you from both mistakes in your own client-side code, and from malicious users who may take your configuration information and try to access the data with that.
To learn more about this, see:
The documentation on security rules in general.
The documentation on security rules for Cloud Firestore.
The documentation on security rules for the Realtime Database.
Many more questions on the topic of Firebase security rules
来源：https://stackoverflow.com/questions/56718206/why-is-it-okay-to-allow-writes-into-firebase-from-the-client-side