Custom functions in rules in Firebase - Commands & Configuration

Introduction

Firebase security rules control who can read or write data. Custom functions let you reuse logic inside these rules to keep them simple and clear.

When you want to check if a user owns a document before allowing access.

When you need to verify if a user has a specific role stored in their profile.

When you want to reuse the same validation logic across multiple parts of your database.

When you want to keep your security rules organized and avoid repeating code.

When you want to make your rules easier to update by changing logic in one place.

Config File - firestore.rules

firestore.rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    function isOwner() {
      return request.auth != null && request.auth.uid == resource.data.ownerId;
    }

    match /posts/{postId} {
      allow read: if true;
      allow write: if isOwner();
    }
  }
}

This file defines Firestore security rules.

rules_version sets the version of the rules syntax.

service cloud.firestore targets Firestore database.

function isOwner() is a custom function that checks if the user is logged in and owns the document by comparing user ID.

match /posts/{postId} applies rules to all documents in the posts collection.

allow read: if true; lets anyone read posts.

allow write: if isOwner(); lets only the owner write to their post.

Commands

Deploys the Firestore security rules with the custom function to Firebase so they take effect.

Terminal

firebase deploy --only firestore:rules

Expected Output

=== Deploying to 'your-project-id'...



✔  Deploy complete!



Project Console: https://console.firebase.google.com/project/your-project-id/overview



✔  Firestore Rules deployed successfully

→

--only firestore:rules - Deploy only Firestore security rules without affecting other Firebase services

Starts the local Firestore emulator to test security rules including custom functions without affecting live data.

Terminal

firebase emulators:start --only firestore

Expected Output

i  emulators: Starting emulators: firestore

✔  firestore emulator started at http://localhost:8080



✔  All emulators started, it is now safe to connect.

→

--only firestore - Start only the Firestore emulator

Runs tests on the Firestore security rules file to verify custom functions work as expected.

Terminal

firebase firestore:rules:test --rules=firestore.rules

Expected Output

Running Firestore rules tests...

All tests passed successfully.

Key Concept

If you remember nothing else from this pattern, remember: custom functions let you write reusable checks inside Firebase security rules to keep them simple and consistent.

Common Mistakes

Writing the same logic multiple times instead of using a custom function.

This makes rules long, hard to read, and error-prone when updating.

Define a custom function once and call it wherever needed in your rules.

Using request.auth.uid without checking if request.auth is null.

If the user is not logged in, this causes errors and denies access incorrectly.

Always check request.auth != null before accessing request.auth.uid.

Deploying rules without testing them locally first.

Mistakes in rules can block all access or open data unintentionally.

Use the Firebase emulator to test rules and custom functions before deploying.

Summary

Create custom functions inside Firestore rules to reuse logic like ownership checks.

Deploy rules using 'firebase deploy --only firestore:rules' to apply changes.

Test rules locally with Firebase emulators to avoid mistakes in live data.

Practice

1. What is the main benefit of using custom functions in Firebase security rules?

easy

A. They make rules easier to read and reuse common checks

B. They automatically fix security vulnerabilities

C. They increase the speed of database queries

D. They replace the need for authentication

Solution

1. Step 1: Understand the purpose of custom functions

   Custom functions in Firebase rules are designed to simplify and organize security logic by reusing common checks.

2. Step 2: Compare options to the purpose

   Only They make rules easier to read and reuse common checks correctly states that custom functions make rules easier to read and reuse common checks. Other options describe unrelated or incorrect benefits.

3. Final Answer:

   They make rules easier to read and reuse common checks -> Option A

4. Quick Check:

   Custom functions improve readability and reuse = A [OK]

Hint: Custom functions simplify and reuse checks in rules [OK]

Common Mistakes:

• Thinking custom functions speed up queries
• Believing they fix security automatically
• Confusing them with authentication features

2. Which of the following is the correct syntax to define a custom function named isOwner in Firebase rules?

easy

A. function isOwner() = request.auth.uid == resource.data.owner;

B. isOwner() => request.auth.uid == resource.data.owner;

C. function isOwner() { return request.auth.uid == resource.data.owner; }

D. isOwner() { return request.auth.uid == resource.data.owner; }

Solution

1. Step 1: Recall Firebase rules function syntax

   Firebase rules use the syntax: function name() { return expression; } to define custom functions.

2. Step 2: Identify the correct syntax

   function isOwner() { return request.auth.uid == resource.data.owner; } matches the correct syntax. isOwner() { return request.auth.uid == resource.data.owner; } omits the required function keyword. Options B and C use invalid syntax.

3. Final Answer:

   function isOwner() { return request.auth.uid == resource.data.owner; } -> Option C

4. Quick Check:

   Firebase custom function syntax uses function name() { return ... } = A [OK]

Hint: Firebase rules functions use function name() { return ... } syntax [OK]

Common Mistakes:

• Omitting the 'function' keyword
• Using arrow functions which are not supported
• Using '=' instead of function body block

3. Given the following Firebase rule snippet:

function isAdmin() { return request.auth.token.admin == true; }
allow write: if isAdmin();

What happens if request.auth.token.admin is false?

medium

A. Write access is denied

B. Write access is granted

C. Rule throws a syntax error

D. Write access is granted only if user is authenticated

Solution

1. Step 1: Understand the function logic

   The function isAdmin() returns true only if request.auth.token.admin is true.

2. Step 2: Evaluate the rule condition

   The write permission is allowed only if isAdmin() returns true. If request.auth.token.admin is false, the function returns false, so write is denied.

3. Final Answer:

   Write access is denied -> Option A

4. Quick Check:

   isAdmin false means no write access = A [OK]

Hint: Function returns false blocks access; true allows it [OK]

Common Mistakes:

• Assuming false admin still grants access
• Thinking rule throws error on false
• Confusing authentication with admin check

4. Identify the error in this Firebase rule custom function:

function isOwner() {
  request.auth.uid == resource.data.owner;
}
allow read: if isOwner();

medium

A. Incorrect function name syntax

B. Invalid comparison operator

C. Using 'allow' outside match block

D. Missing return statement inside the function

Solution

1. Step 1: Check function body for return

   The function compares values but does not return the result, so it returns null by default.

2. Step 2: Understand impact on rule

   Without a return, isOwner() returns null (falsey), so the rule will deny access unexpectedly.

3. Final Answer:

   Missing return statement inside the function -> Option D

4. Quick Check:

   Functions must return values explicitly = B [OK]

Hint: Always return a value in custom functions [OK]

Common Mistakes:

• Forgetting to add 'return' before expression
• Assuming last line auto-returns value
• Misplacing 'allow' statements

5. You want to create a reusable custom function canEdit() that allows editing if the user is either the owner or has an admin role. Which of the following is the correct way to write this function in Firebase rules?

hard

A. canEdit() { if (request.auth.uid == resource.data.owner) return true; else return false; }

B. function canEdit() { return request.auth.uid == resource.data.owner || request.auth.token.admin == true; }

C. canEdit() { return request.auth.uid == resource.data.owner || request.auth.token.admin == true; }

D. canEdit() { return request.auth.uid == resource.data.owner || request.auth.token.admin; }

Solution

1. Step 1: Understand the logic needed

   The function should return true if the user is owner OR has admin role.

2. Step 2: Analyze each option

   function canEdit() { return request.auth.uid == resource.data.owner || request.auth.token.admin == true; } correctly uses function keyword, logical OR (||) and explicit admin comparison. canEdit() { if (request.auth.uid == resource.data.owner) return true; else return false; } only checks owner. canEdit() { return request.auth.uid == resource.data.owner || request.auth.token.admin == true; } and canEdit() { return request.auth.uid == resource.data.owner || request.auth.token.admin; } omit required function keyword.

3. Final Answer:

   function canEdit() { return request.auth.uid == resource.data.owner || request.auth.token.admin == true; } -> Option B

4. Quick Check:

   function keyword + OR + admin == true = B [OK]

Hint: Use function keyword, || and explicit admin == true check [OK]

Common Mistakes:

• Using AND instead of OR for conditions
• Not explicitly comparing admin to true
• Ignoring admin role in logic