Skip to main content

introduce

Security Rules​

Introduction​

Security Rules represent a more advanced, flexible, and scalable permission control approach built upon basic permission management, specifically designed to protect user cloud data security.

Why are Security Rules needed?​

Basic Access Control is a preset permission group based on common scenarios during development, capable of implementing simple permission management. However, as application business scenarios become increasingly complex, this management approach can no longer meet the need for fine-grained control based on conditions such as user roles or login modes.

Under the traditional basic access control model, to implement complex permission management, developers need to:

  • Centralize all client-side operations within Cloud Functions
  • Write validation logic within Cloud Functions
  • Indirectly implement access control through this approach

In contrast, with Security Rules, developers can:

  • Customize precise control conditions
  • Accomplish permission configuration through concise rule statements
  • Automate access control based on rules
  • Implement data validation and other more advanced features

Security Rules utilize a JSON-based extensible configuration language to clearly define the scope of database and storage resources accessible to users. Developers can write simple or complex rules based on the granularity of application requirements to comprehensively protect application data.

Core Advantages​

  1. High Flexibility - Developers can customize rules based on business characteristics, supporting dynamic access control based on application data itself, enabling conditional data access policies.

  2. Fine-Grained Granularity - Rules can be precisely defined down to the field level, allowing the configuration of simple or complex access conditions based on requirements to meet security needs across various scenarios.

  3. Security and Independence - Rules are independently configured on the management side, completely decoupled from the application business logic:

    • Clients cannot obtain rule content
    • Rule validation cannot be bypassed
    • Ensure all data access undergoes strict validation

  4. Development Convenience - Achieve access control through configuration-based rules:

    • No need to develop additional access layer control code
    • Eliminates the need for complex deployment processes
    • Supports rapid validation and adjustment

How It Works​

The workflow of Security Rules is as follows:

  1. Rule Retrieval - When a user attempts to access data, the system first retrieves the complete rule configuration (JSON format) set on the management side.
  2. Operation Matching - The system matches the corresponding rule configuration based on the operation type of the request (such as read, write, etc.)
  3. Rule Parsing - The configuration value can be:
    • Simple Boolean values (true/false)
    • A logical expression string with JavaScript-like syntax
  4. Permission Determination - Allow access when the Boolean value is true or the expression evaluates to true; otherwise, deny access.
  5. Operation Execution - The system executes subsequent data operations only when access is permitted.

Basic Rules Configuration Example​

{
    // Read permission: set to false means read is prohibited
    "read": false,
    
    // Write permission: dynamically determined using conditional expressions
    "write": <<condition>>
}

Expressions can use built-in variables to obtain the identity information and metadata of requests, enabling complex logical judgments. For an in-depth understanding of rule syntax and available variables, please refer to Rule Language Details.

Billing Description​

The security rules feature itself is completely free, with no additional charges. However, note that:

  • When metadata variables (such as doc, resource) or retrieval functions (such as get) are used in rules, read operations will be incurred on the corresponding resources.
  • These read operations will consume the usage quota of the corresponding resources.
  • The billing method follows the respective billing rules for each resource.

Usage Limits​

Expression Limits​

  • The maximum length of each expression (group) is limited to 1024 characters

Supported Syntax Elements​

  • Variables: Support various variable references (regular expressions are not supported)
  • Array expressions: Array members are restricted to numeric or string types
  • Logical expressions: Support logical operators such as && (AND), || (OR)
  • Unary expressions: Support unary operations such as +1, -1, !a
  • Binary expressions: Support comparison operators such as >, >=, <, <=, ==, !=, in
  • Member expressions: Support member access methods such as a.b, a["b"]
  • Call expressions: Function calls are supported only in database security rules.
  • String template expressions: Used for dynamic parameters in database function calls, for example: `database.collection.\${doc.objectId}`