Security Rules for Pipeline operations

While Pipeline operations offer a rich set of features, the Rules engine is restricted to recognizing comparison (e.g. >) and logical (e.g. or) filters to ensure constraint satisfiability and security.

Supported Filter Expressions

For Pipeline operations to be constrained to the bounds set by your rules, it must use logical and comparison operators against constants. The following filter types are recognized by the Rules engine:

• Comparisons: eq, neq, gt, gte, lt, lte, in, arrayContains.
• Logical: and, or.

Here are some examples:

• where(eq("foo", 2))
• where(lt("foo", 2))
• documents("/user/1", "/user/2").where(...)

Request Properties

You can continue to use the request object to validate authentication and query context, though some properties available in standard queries are not supported in Pipeline operations.

Supported properties

The new engine continues to support the following properties:

• request.auth: Access user uid and token data.
• request.method: Identifies the operation (For example, get, list).
• request.path: The path of the resource being accessed.
• request.time: The server-side timestamp of the request.

Unsupported properties

The request.query properties such as limit, offset, and orderBy are unsupported for Pipeline operations rule checks due to the complexity of determining these values in multi-stage queries.

Pipeline stage handling and permissions

There are different pipeline stages that map to specific granular operations in security rules:

• allow list permissions: Triggered by collection(), collectionGroup(), and database() stages.
• allow get permissions: Triggered by the documents() stage, which is treated similarly to a batch get operation.
• Literals stage: The literals() stage does not read from the database but can incur costs. To prevent abuse, it must be paired with another stage (like collection()) that can be verified by rules.

Field modification stages

Rules only operate on stored data and not derived values. If a pipeline includes stages that modify fields (For example, add_fields(...), replace_with(...), select(...), remove_fields(...)), the Rules engine stops applying filter constraints after that stage is encountered. To ensure that rules works as expected, position your filter stages (i.e. where) before any stages that can modify the original stored documents.

For example, take the following security rule:

match /databases/{database}/documents {
  match /cities/{city} {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    allow read: if resource.data.visibility == 'public';
  }
}

Denied: This rule rejects the following pipeline because the addFields stage occurs before filtering to documents where visibility is public:

const results = await db.pipeline()
  .collection("/cities")
  // Filters after a modification stage are ignored by Rules.
  .addFields(constant(1000).as("population"))
  .where(eq(field("visibility"), constant("public")))
  .execute();

Allowed: This rule allows the following pipeline because the where(eq(field("visibility"), constant("public"))) stage occurs before any modification stages:

const results = await db.pipeline()
  .collection("/cities")
  .where(eq(field("visibility"), constant("public")))
  .addFields(constant(1000).as("population"))
  .execute();