Firebase Realtime Database Rules determine who can read and write access to your database.
Maybe you’re the guy who doesn’t give a shit about the rules. 😂
The rules are critical for security as explained by a Googler in the I/O event.
Did you know?
Firebase servers store rules for security purposes.
Moreover, you can alter your rules from Firebase Console.
How can you do that?
Select your project, click Database and hit Rules.
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.
.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.\
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.
Just Authenticated Users Can Write (Access) Data
Users can write and read data if they are authenticated into the app.
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.
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.
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.
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.
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.
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.
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.
Ask any questions in the comment section below, our experts will be happy to help you at no extra cost.