31 Introduction to Security Rules
This chapter provides an overview of the security rules and the rule evaluation model.
Parent topic: Security Rules
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.authcan 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, andupdate. -
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’sCountryfield is"India". -
write: Allows write access only if the user is authenticated and their UID matches theownerIdfield 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
Parent topic: Introduction to Security Rules
31.2 Evaluation Model and Application Scope
Rule Evaluation Model
Security rules are evaluated based on three primary components:
-
Request Context (
request)-
Represents the incoming request from the client SDK or REST API
-
Includes authentication details, request method, path, and payload
-
-
Resource Context (
resource)-
Represents the existing data stored in the backend
-
Used to compare against the request data for conditional access
-
-
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
Parent topic: Introduction to Security Rules
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.
Security rules are:
-
Defined per collection or file path using the
matchblock -
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
Parent topic: Introduction to Security Rules