31 Introduction to Security Rules

This chapter provides an overview of the security rules and the rule evaluation model.

31.1 Purpose and Scope

Security Rules in Oracle Oracle Backend for Firebase are written using a CEL (Common Expression Language)-based syntax and are evaluated at runtime to determine whether a request should be allowed or denied.

Unlike traditional role-based access control, Oracle Backend for Firebase's security rules are context-aware, meaning they can inspect both the request metadata and the resource data to make dynamic decisions. This allows developers to enforce policies like:

  • Only the owner of a document can update a file or document.

  • request.auth can help in making a document private for specific user.

  • Attribute level rules can be written to help deny/accept request.

Security rules in Oracle Backend for Firebase are written using CEL (Common Expression Language) expressions. These rules control access to database operations like read, write, delete, list, and get.

Following are the key points of security rules:

  • Rules are stored and managed via the Oracle Backend for Firebase Console.

  • Collection group rules are supported.

  • Rules are evaluated per operation—so you can define different logic for operations such as delete, list, get, create, and update.

  • Each rule is scoped to a specific collection or document path and evaluated against the incoming request and resource data.

Example 31-1 Security Rules

IF you have a collection called Cities. You want to allow users to read documents only if the Country field is "India", define the rule as follows:

{
  "read": "resource.data.Country == 'India'",
  "write": "request.auth != null && request.auth.uid == resource.data.ownerId"
}
  • read: Allows read access only if the document’s Country field is "India".

  • write: Allows write access only if the user is authenticated and their UID matches the ownerId field of the document.

The following variables are available:

  • request.auth: Contains authentication info (for example, uid, email)

  • request.time: Timestamp of the request

  • request.resource: Incoming data

  • resource.data: Existing document data

31.2 Evaluation Model and Application Scope

Rule Evaluation Model

Security rules are evaluated based on three primary components:

  1. Request Context (request)

    • Represents the incoming request from the client SDK or REST API

    • Includes authentication details, request method, path, and payload

  2. Resource Context (resource)

    • Represents the existing data stored in the backend

    • Used to compare against the request data for conditional access

  3. Rule Expression

    • A CEL-based boolean expression that determines access

    • If the expression evaluates to true, the request is allowed

Rule Application Scope

Security rules are applied to the following Oracle Backend for Firebase services:

  • Authentication: Validates identity and token claims, but authorization is enforced via rules

  • Database: Controls access to documents, collections, subcollections, joins, and duality views

  • Object Storage: Governs file uploads, downloads, deletions, and public URL generation

Rules can be defined, tested, and deployed using the Console UI or SDK methods

31.3 Key Capabilities

The Oracle Backend for Firebase rule engine supports:

  • Logical and comparison operators such as ==, !=, <, >, &&, ||

  • String and list functions such as lower(), .split(), .hasAll(), size()

  • Timestamp functions such as year(), .month(), .dayOfWeek()

  • Macros such as exists(path), get(path)

  • Nested conditions and wildcard path matching

These capabilities allow developers to write expressive, maintainable, and secure access policies.

See Also:

For a complete list of supported operators and functions, see:

Operators and Functions

Security rules are:

  • Defined per collection or file path using the match block

  • Validated automatically during deployment through CEL conversion

  • Enforced at runtime by the Oracle Backend for Firebase backend infrastructure

The Console UI provides a rule editor with syntax validation, and the Console allows rule simulation and testing before deployment. Each service allows rules to be defined using the Console UI:

  • Select the target collection or file path

  • Choose the operation (such as get, create)

  • Write the CEL expression

  • Validate and publish the rule