10 Simple Examples of Firebase Realtime Database Rules

Who has read and write access to your database is determined by Firebase Realtime Database Rules.

Realtime Database Rules

Maybe you're the kind of person who doesn't care about the rules.

According to a Googler at the I/O event, the rules are crucial for security.

What if I told you that?

For security reasons, Firebase servers store rules.

You can also change your rules through the Firebase Console.

How are you going to do that?

It's that easy.

Choose your project, then Database, then Rules.

Four Different Types of Firebase Realtime Database Rules:

  • .read has complete access to all data.
  • .write is capable of editing, creating, and deleting any type of data.
  • .Validate can check the data's format.
  • We may use .indexOn to construct an index so that we can easily sort and query the data.

10 Examples of Firebase Realtime Database Security Rules

The 10 examples of security rules for Firebase Realtime databases are listed below.

1. No Security

If you set .write= true and .read= true, anyone can write and read your database, even if they aren't a user of your application.

You can establish public rules throughout the construction of the application so that you can easily write and read your database.

Keep in mind that you should never use No Security Rules in production; otherwise, anyone can access your sensitive data.

It's great for prototyping, especially if authentication isn't a must for your project.

// No Security
{
 “rules”: {
 “.read”: true,
 “.write”: true
 }
}

2. Full Security

By default, these rules are available.

You won't be able to write or read to your database if you use Full Security Rules.

You can access your database through the Firebase Console Dashboard if you're adding these rules.

// Full security
{
 “rules”: {
 “.read”: false,
 “.write”: false
 }
}

3. Only Authenticated Users have Permission to Write (access) Data

If a user is authenticated into the app, they can write and read data.

//Data can only be accessed/written by authenticated users. 
{
 “rules”: {
 “.read”: “auth != null”,
 “.write”: “auth != null”
 }
}

4. User Authentication from a Unique Domain

When you only want to authenticate users who are registered from a specific domain, this rule comes in handy.

//Data can only be accessed/written by authenticated users from a specific domain (example.com).
{
 “rules”: {
 “.read”: “auth.token.email.endsWith(‘@example.com’)”,
 “.write”: “auth.token.email.endsWith(‘@example.com’)”
 }
}

5. User Data Only

Firebase authenticates the access granted by users.

$uid is the unique ID of every Firebase authenticated user, as demonstrated in the code below, and $uid also symbolises a wildcard.

The Firebase database provides a wildcard path for describing dynamic child keys and IDs.

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

6. Simply validate the user from several database locations

You can also validate a user from a specific database location.

“users” is a child node given anywhere in the database that has a child node of “moderator” in the example below.

You can validate if the "moderator" node value equals "true."

//Verifies that the user is a moderator from a distinct database.
{
 “rules”: {
 “posts”: {
 “$uid”: {
 “.write”: “root.child(‘users’).child(‘moderator’).val() === true”
 }
 }
 }
}

7. Validate the length of the string and the datatype

You can also check the length and datatype of any String.

I gave three rules in the example below.
  • The first is “newData.isString(),” which indicates that the datatype is string.
  • The second string value for "newData.val().length > 0" must not be null.
  • The third string value for "newData.val().length = 140" must be fewer than 141 characters.
//Validates the datatype and length range of strings.
{
 “rules”: {
 “posts”: {
 “$uid”: {
 “.validate”: “newData.isString() 
 && newData.val().length > 0
 && newData.val().length <= 140”
 }
 }
 }
}

8. Check for the presence of child attributes

You may also see if a specific child node exists in the database.

In the example below, I specified an array that contains the database's child nodes "['username','timestamp'].

//The presence of child characteristics is checked.
{
 “rules”: {
 “posts”: {
 “$uid”: {
 “.validate”: “newData.hasChildren([‘username’, ‘timestamp’])”
 }
 }
 }
}

9. Validate the Timestamp

“newData.val() = now” is used in the example below. You can verify data that has been entered recently or in the past.

In milliseconds, “now” denotes the current available time.

//Validates that the timestamp is not in the future.
{
 “rules”: {
 “posts”: {
 “$uid”: {
 “timestamp”: { 
 “.validate”: “newData.val() <= now” 
 }
 }
 }
 }
}

10. Updating and Preventing Deletion

In the example below, “!data.exists()” allows you to write data to the database even if it isn't already there. You cannot delete or alter data once it has been added.

//Stops you from deleting or updating your data.
{
 “rules”: {
 “posts”: {
 “$uid”: {
 “.write”: “!data.exists()”
 }
 }
 }
}

Post a Comment

Previous Post Next Post