Firebase Says That My Rules Are Insecure, Why

Firebase email saying my realtime database has insecure rules

firebaser here

I'm sorry if the email wasn't very explicit about what isn't secure about those rules. Securing your user's data is a crucial step for any app that you make available, so I'll try to explain a bit more about how that works below.

The (default) rules you have allow anyone who is signed in to your back-end full read/write access to the entire database. This is only a very basic layer of security.

On the one hand this is more secure than just granting everyone access to your database, at least they have to be signed in.

On the other hand, if you enable any auth provider in Firebase Authentication, anyone can sign in to your back-end, even without using your app. Depending on the provider, this can be as easy as running a bit of JavaScript in your browser's developer console. And once they are signed in, they can read and write anything in your database. This means they can delete all data with a simple command like firebase.database().ref().delete().

To make the data access more secure, you'll want to more tightly control what each signed-in user can do. For example, say that you keep a profile with information about each user under /users. You might want to allow all users to access these profiles, but you definitely want users to only be allowed to modify their own data. You can secure this with these rules:

{
"rules": {
"users": {
".read": true,
"$user_id": {
// grants write access to the owner of this user account
// whose uid must exactly match the key ($user_id)
".write": "$user_id === auth.uid"
}
}
}
}

With these rules, everyone (even non-authenticated users) can read all profiles. But each profile can only be modified by the user whose profile it is. For more on this, see the Firebase documentation on securing user data.

In addition to ensuring that all access to data is authorized, you'll also want to ensure that all data stored is valid to whatever rules you have for you app. For example, say that you want to store two properties for a user: their name, and their age (just for the sake of the example, in reality you'd probably store their date-of-birth instead). So you could store this as something like:

"users": {
"uidOfPuf": {
"name": "Frank van Puffelen",
"age": 48
}
}

To ensure only this data can be written, you can use this rules:

{
"rules": {
"users": {
".read": true,
"$user_id": {
".write": "$user_id === auth.uid",
".validate": "data.hasChildren('name', 'age')",
"name": {
".validate": "data.isString()",
},
"age: {
".validate": "data.isNumber()",
},
"$other: {
".validate": false
}
}
}
}
}

These rules ensure that each user profile has a name and age property with a string and numeric value respectively. If someone tries to write any additional properties, the write is rejected.

Above is a quick primer on how to think about securing your (user's) data. I recommend that you check out the Firebase security documentation (and the embedded video) for more.


Update: since May 2021 you can also use Firebase App Check to restrict access to calls just coming from your web site or app. This is another, quick way to reduce the abuse of your database. This approach is not foolproof though, so you'll want to combine App Check for broad protected, with the security rules for fine-grained control.

Firebase says that my rules are insecure, why?


".read": "auth != null",

".write": "auth != null",

These above rules are default rules. According to firebase documentation They allow full read and write access to authenticated users of your app. They are useful if you want data open to all users of your app but don't want it open to the world

It is essential that you configure these rules correctly before launching your app to ensure that your users can only access the data that they are supposed to.

{
"rules": {
"foo": {
".read": true,
".write": false
}
}
}

Here's an example of a rule that grants write access for authenticated users to /users//, where is the ID of the user obtained through Firebase Authentication.

{
"rules": {
"users": {
"$uid": {
".write": "$uid === auth.uid"
}
}
}
}

Firebase] Your Realtime Database '***[project name]' has insecure rules

Your security rules are right, but as the documentation says and the warning:

While we don't recommend leaving your data accessible to any user that's signed in, it might be useful to set access to any authenticated user while you're developing your app.

they are not enough, because if anyone wants your data, they can log in and take them all, which is of course big security issue.

So be more specific about what you want users to read, make them only read their data for example , or shared data .

But eventually it depends on the data you stored, if you want all uses to read them(they are not a secret) then don't give this warning another thought.

Firebase your realtime database has insecure rules warning

The syntax does not seem correct to refer to a child resource, check below syntax to achieve the desired effect

{
"rules": {
"some_path": {
"$uid": {
".write": "$uid === auth.uid"
}
}
}
}

https://firebase.google.com/docs/database/security

Google keeps warning insecure rules

That a user needs to be able to read all data in the database, doesn't mean they need to be able to read the root of the database.

That a user needs to be able to write to the database, doesn't mean they need to be able to write to the root of the database.

In both scenarios your code probably doesn't read the root, and it definitely doesn't simply write to the root - as that would overwrite the data from the other users.

Your rules should allow exactly how you code accesses the data, and nothing more. This is known as the principle of least privilege - and is a common practice in securing systems.

Also see:

  • How safe is auth !== null? Firebase
  • Firebase says that my rules are insecure, why?
  • Firebase email saying my realtime database has insecure rules
  • How to secure Firebase by checking for correct userID in the "official" Authentication database
  • Firebase Realtime Database Security Rules for prevent create/delete not working

Finally I recommend checking out Firebase App Check too, which drastically reduces the chances of abuse from users that use your configuration data but not your code.

Firebase Realtime database - insecure rules


anyone visiting the site should be able to read the data.

While that is a valid requirement, right now even people who are not visiting your web site can read the entire database with a single call. In fact, it's as simple as opening the URL https://<yourproject>.firebaseio.com/.json (or a similar URL for your region) to scrape all data from our database.

Typically your code will access the data in a more granular level. In fact, looking at your rules, I expect that your code runs queries or accesses individual child nodes of CollectionOne and CollectionTwo. If that is what your application code does, it is also all that you security rules should allow.

So one step better would be:

{
"rules": {
".write": "(auth != null) && (auth.uid == '123...myUID ...xyz')",
"CollectionOne": {
".read": true,
".indexOn": ["name", "url"]
},
"CollectionTwo": {
".read": true,
".indexOn": ["name"]
}
}
}

Now the URL patterns I showed above won't work anymore, and a malicious user must know the name of your top-level nodes in order to access the data in them.

For more on this, also see:

  • What security rules should be applied to reads in Firebase?
  • Firebase email saying my realtime database has insecure rules

Firebase Your Cloud Firestore database has insecure rules for basic Security Rules

I can think of two solutions without risking compromising security (to some extent):

  1. You can use Authentication for users and only allow read or write access to authenticated users. (Which I understand is a hassle specially when coding a game.) like so:
match /databases/{database}/documents {
match /{document=**} {
allow write: if request.auth != null;
}
}
}

  1. You can use some sort of 10-char sequence for example combined with the document names in your database (for example, "Users-xQnFiECweq") and then edit your security rules accordingly.

for example:

match /Users-xQnFiECweq {
match /Courses-QrmGvMgF9C {
match /{multiSegment=**}{
allow write;
}
}
}

the string values at the end of document or collection names kind of act as passwords that only you know and it makes it difficult for another person to guess the exact structure to your database.

I understand it's a bit of a strange approach but it's better than giving write access to just everyone.

Firebase, insecure rules

The emails are because the rules aren't really stringent. You should probably be using the following rule, that:

  1. Allows unauthenticate users to read data
  2. Allows authenticated users to create entries
  3. Allows to update & delete entries that are only owned by themselves and not of others.
service cloud.firestore {
match /databases/{database}/documents {
// Allow public read access, but only content owners can write
match /some_collection/{document} {
allow read: if true
allow create: if request.auth.uid == request.resource.data.author_uid;
allow update, delete: if request.auth.uid == resource.data.author_uid;
}
}
}

Read this article for better understanding. You can also check when firestore flags rules as insecure over here. More importantly, this is the point to be emphasized.

Remember that Firebase allows clients direct access to your data, and
Firebase Security Rules are the only safeguard blocking access for
malicious users. Defining rules separately from product logic has a
number of advantages: clients aren't responsible for enforcing
security, buggy implementations will not compromise your data, and
most importantly, you're not relying on an intermediary server to
protect data from the world.

Sample rules:

service cloud.firestore {
match /databases/{database}/documents {
match /users/{userDoc} {
allow read: if true
allow create: if request.auth.uid == request.resource.data.id;
allow update, delete: if request.auth.uid == resource.data.id;
}

match /posts/{postDoc} {
allow read: if true
allow create: if request.auth.uid != null;
allow update, delete: if request.auth.uid == resource.data.user_id;
}

match /comments/{commentDoc} {
allow read: if true
allow create: if request.auth.uid != null;
allow update, delete: if request.auth.uid == resource.data.user_id;
}
}
}


Related Topics



Leave a reply



Submit