4 Types of Firebase Realtime Database Rules:

• .read has the power to access all the data.
• .write has the ability to edit, create, and delete any kind of data.
• .validate can check the format of the data.
• .indexOn allows us to create an index so that we can order and query the data effortlessly.

10 Examples of Security Rules of Firebase Realtime Databases

Below are the ten examples regarding the security rules of Firebase realtime databases.

1. No Security

.write= true & .read= true means everyone is able to write and read your database even if it is not a user of your application.

During the development of the application, you can set public rules so that you can easily write and read your database easily.

Keep in mind, don’t ever use in the production No Security Rules otherwise, anyone can access your important data.

You can use it for prototyping especially when authentication isn’t an essential part of your app.\

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

view rawrealtimeDatabaseRules_NoSecurity.java hosted with ❤ by GitHub

2. Full Security

These rules are provided by default.

In Full Security Rules, you can’t write and read access to your database.

If you are adding these rules, you can just access your database in the Firebase Console Dashboard.

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

view rawrealtimeDatabaseRules_FullSecurity.java hosted with ❤ by GitHub

3. Just Authenticated Users Can Write (Access) Data

Users can write and read data if they are authenticated into the app.

	// Only authenticated users can access/write data
	{
	“rules”: {
	“.read”: “auth != null”,
	“.write”: “auth != null”
	}
	}

view rawrealtimeDatabaseRules_AuthUsers.java hosted with ❤ by GitHub

4. Authenticate User from a Special Domain

The rule is useful when you want to authentic your users only if they’re registered from a particular domain.

	// Only authenticated users from a particular domain (example.com) can access/write data
	{
	“rules”: {
	“.read”: “auth.token.email.endsWith(‘@example.com’)”,
	“.write”: “auth.token.email.endsWith(‘@example.com’)”
	}
	}

view rawrealtimeDatabaseRules_AuthFromParticularDomain.java hosted with ❤ by GitHub

5. User Data Only

Users grant access which is authenticated by Firebase.

Here $uid, shown in the below code example, is the unique ID of every Firebase authenticated user and $uid also represents a wildcard.

Firebase database gives a wildcard path that is used to describe dynamic child keys & IDs.

I’ve also explained in detail wildcard in Firebase Storage Rules.

	// These rules grant access to a node matching the authenticated
	// user's ID from the Firebase auth token
	{
	"rules": {
	"users": {
	"$uid": {
	".read": "$uid === auth.uid",
	".write": "$uid === auth.uid"
	}
	}
	}
	} realtimeDatabaseRules_UserDataOnly.java hosted with ❤ by GitHub Just Validate User from the Different Location in the Database You can also validate the user from a specified location in the database. In the below example “users” is a child node specified anywhere in the database which contains a child node of “moderator“. If the “moderator” node value is equal to “true” then you can validate. // Validates user is moderator from different database location { “rules”: { “posts”: { “$uid”: { “.write”: “root.child(‘users’).child(‘moderator’).val() === true” } } } } view rawrealtimeDatabaseRules_ValidateUserFromDiffLocation.java hosted with ❤ by GitHub Validate String Length and Datatype You can even validate the length or datatype of any kind of String. In the below example, I specified three rules. First “newData.isString()” which define that the datatype is in string format. Second “newData.val().length > 0” string value must not be null. Third “newData.val().length <= 140” string value must be less than 141 character. // Validates string datatype and length range { “rules”: { “posts”: { “$uid”: { “.validate”: “newData.isString() && newData.val().length > 0 && newData.val().length <= 140” } } } } view rawrealtimeDatabaseRules_ValidateString.java hosted with ❤ by GitHub Check Child Attributes Presence You can also check the presence of a specific child node in the database. In the below example “[‘username’, ‘timestamp’]”, I specified an array which contains the child nodes in the database. // Checks presence of child attributes { “rules”: { “posts”: { “$uid”: { “.validate”: “newData.hasChildren([‘username’, ‘timestamp’])” } } } } view rawrealtimeDatabaseRules_PresenceOfChildAttr.java hosted with ❤ by GitHub Validate the Timestamp In the below example “newData.val() <= now” You can validate your data that is placed right now or available in the past. “now” represents the current available time in Milliseconds. // Validates timestamp is not a future value { “rules”: { “posts”: { “$uid”: { “timestamp”: { “.validate”: “newData.val() <= now” } } } } } view rawrealtimeDatabaseRules_ValidateTimestamp.java hosted with ❤ by GitHub Preventing Deletion and Updations In the below example, “!data.exists()”  allows you to write data in the database if the data is not available in the database. Once the data is added then you can’t delete or update the data. // Prevents Delete or Update { “rules”: { “posts”: { “$uid”: { “.write”: “!data.exists()” } } } } view rawrealtimeDatabaseRules_preventsDelete&Update.java hosted with ❤ by GitHub

view