GOOGLE FIREBASE DETAILED SECURITY RULES Part 2

This is follow on post from Google Firebase detailed security rules part 1.

Advanced Rules

Only allow user to edit or add their own

This prevents other users from modifying other users content. Here’s an example of Firebase Realtime Database. 

"users": {
      "$user_id": {
        ".write": "data.child('user_id').val() === auth.uid || newData.child('user_id').val() === auth.uid"               
        }
}

Similarly in Firebase Storage rules. Allows authenticated users to read the users image. This example show folders and child folders to help apply different rules for each folder. 

match /user-images {
      // Allow all to read each other's profile if authenticated
      allow read: if request.auth != null;
      
      match /{user_id} {
      // Only allow current user to write to its own folder
      	allow write: if request.auth.uid == user_id;
        allow read: if request.auth != null;
        
        match /{allPaths=**} {
        	allow read: if request.auth != null;
      		allow write: if request.auth.uid == user_id;
        }
      }
}

Multi-layer permission

Sometimes one key will need a different permission than the rest of the keys in the Firebase Realtime Database. 

"users": {
      "$uid": {
        ".write": "$uid === auth.uid",
        "key1": {
          ".write": "auth != null"
        },
        "key2": {
          ".write": "auth == null"
        },
        "key3": {
          ".write": "auth === auth.uid"
        },
        "key4": {
          ".write": "auth != auth.uid"
        }
      }
  }

In Firebase Storage. Allow only authenticated users to read in the /users/ folder. Then in /users/1233/ only allow the owner to write and others who are authenticated to read. In the folder /users/1233/anotherFolder/ read for all authenticated and write for owner. Last, /users/private/ only the owner is able to read and write. 

match /users{
      allow read: if request.auth != null;
      
      match /{user_id} {
      	allow write: if request.auth.uid == user_id;
        allow read: if request.auth != null;
        
        match /{allPaths=**} {
        	allow read: if request.auth != null;
      		allow write: if request.auth.uid == user_id;
        }

        match /private {
      		allow write: if request.auth.uid == user_id;
        	allow read: if request.auth.uid == user_id;
      	}
      }
    }

More info checkout https://firebase.google.com/docs/database/security Don’t forget to subscribe below for more cloud engineer posts!

As always if you see any errors, mistakes, have suggestions or questions please comment below. Don’t forget to like, share, and subscribe for more! 

Waleed S.Leave a comment

Google Firebase detailed security rules Part 1

I’ll be showing you how Google’s Firebase security rules in detail with my custom iOS app with slight changes. In addition to securing your Google Firebase API’s, you must also secure your Firebase Realtime Database. This is secured by applying security rules to the database in the Firebase console. I highly recommend using the provided simulator to test and verify the expected results that you expect for your web or application! I will not be responsible for your misconfiguration or lack of understanding of what this article entails.

Basic rules

100% Closed

// These rules don't allow anyone to read or write access to your database
{
  "rules": {
    ".read": false,
    ".write": false
  }
}

This is the MOST restrictive rule, no one is allowed to do any CRUD operations. Also, this is the least useful one. (I don’t know why I even bothered with typing this 🙂 let’s continue)

This below is open for anyone in the world to read and write, even worse than the most restrictive security rules.

100% Open


// OPEN TO THE WHOLE WORLD
// read and write access to your database
{
  "rules": {
    ".read": true,
    ".write": true
  }
}

This one below is a good starting point but it does require modification depending on your needs. If you’re going to have users sign up and sign in functionality then start with this.

User ID based

// These rules grant access to a node matching the authenticated
// user's ID from the Firebase auth token
{
  "rules": {
   ".read": "auth != null",
    "users": {
      "$uid": {
        ".read": "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

The first rule means only authenticated users can read everything! Which is most likely what you want to start with. The second rule says only information from the “users” tree that has a node ID that is equal to the current user’s ID, may have full read and write permissions on that exact node. In the example below, the current user has full access to node1, not node2. 

// assume current user id is 22222222222

someApp-1234
 users
  node1: 11111111111
    key: value
    key: value
  node2: 22222222222
    key: value
    key: value

References

Waleed S.1 Comment