Access Rules

Three rules per collection

Every collection carries three independent rules — one each for reading, writing, and deleting. You set them when you create the collection (and can change them later):

{
  "name": "documents",
  "read_rule": "scoped",
  "write_rule": "owner",
  "delete_rule": "owner",
  "owner_field": "org_id"
}

• read_rule governs get and query. Default: authenticated.
• write_rule governs both insert and update — there is no separate insert rule. Default: authenticated.
• delete_rule governs delete and deleteWhere. Default: owner.

A write or delete rule can never be public — writing always requires an identified user. public is a read-only tier.

The five rule types

owner and scoped look similar but answer different questions. Owner is about authorship — it keys off created_by, the user who created the record. Scoped is about tenancy — it keys off a field you name (owner_field, e.g. org_id or team_id), so an entire team or organization shares access regardless of who created each record.

When the record field and the caller's identity don't share a name, bind them explicitly: owner_field: "user_id=$caller.id" matches the record's user_id against the signed-in user's id — the same idea as Firebase's request.auth.uid or Supabase's auth.uid(). A plain field name keeps the same-name convention. The caller's context contains id, email, full_name, plus any keys from the user's metadata.

Conditional rules

A conditional rule is a list of comparisons combined by rule_mode — all (every condition must hold) or any (at least one). Each condition compares a record field to either a literal value or the caller's own value for that field:

{
  "name": "tasks",
  "read_rule": "conditional",
  "rule_mode": "all",
  "rule_conditions": [
    { "type": "equals", "field": "org_id", "source": "user" },
    { "type": "in",     "field": "status", "value": ["open", "in_progress"] }
  ]
}

• type — one of equals, not_equals, in, not_in.
• field — the record field being compared.
• source: "user" — compare against the caller's own value for that field. Omit source and supply value to compare against a fixed literal.

The example reads as: a caller may read a task only if its org_id equals the caller's org_id and its status is open or in progress.

Condition quick reference

// Compare record field to the caller's same-named field
{ "type": "equals", "field": "org_id", "source": "user" }

// Compare record field to a literal value
{ "type": "equals", "field": "status", "value": "active" }

// Check record field against a list
{ "type": "in", "field": "role", "value": ["admin", "manager"] }

Lookup conditions

Two condition types check whether a record exists in another collection before allowing a write: exists and not_exists. They express relationships that field comparisons can't — allow-lists, membership checks, and blocking.

A lookup names a target collection and a where map. Each where value is a literal, or a binding: $record.<field> reads the incoming record, $caller.id (or any context key) reads the signed-in user.

The canonical example — server-enforced user blocking. Messages carry a recipient_id; a write is rejected when the recipient has blocked the sender:

// messages write rule: conditional
[{
  "type": "not_exists",
  "collection": "blocks",
  "where": {
    "user_id":         "$record.recipient_id",
    "blocked_user_id": "$caller.id"
  }
}]

Reading: the insert passes only when no blocks record exists where user_id equals the message's recipient and blocked_user_id equals the sender. A blocked sender receives permission_denied — the message never lands.

How rules apply, per operation

Reads

query applies the rule as a filter — owner and scoped reads automatically narrow results to the caller's own records, and conditional reads drop rows that don't match. A get by id runs the same check on the one record; if it fails, you get a record_not_found — identical to a record that truly doesn't exist. Reads never reveal that a record they can't see exists.

Writes

Every write requires an identified user. scoped and conditional writes are validated against the data being written, so you can't create or update a record into a scope that isn't yours. An update is additionally checked after the change is applied: it can't reassign owner_field to another tenant, and a conditional record must still satisfy the rule once patched. A record can't be edited out of your reach.

Deletes

Single deletes run the delete rule on the target record. deleteWhere applies the same rule as a scope on the bulk operation — an owner or scoped bulk delete only ever touches the caller's own records.

When a request is denied

Denials are deliberate and consistent across reads, writes, and deletes:

Elevated access

Access rules govern the direct client SDK. Two callers are elevated and bypass them: your Cloud Functions (which run with a trusted system identity) and the dashboard back-office. Inside a Function, the database is unrestricted — authorization there is your responsibility, via ctx.auth — the same model as Firebase Admin.