Security rules

Rules live under rls in an entity schema, one per operation: create, read, update, delete.

Rule values

Record fields are addressed as data.<field>; the creator is created_by. Templates: {{user.email}}, {{user.id}}, {{user.role}}, {{user.data.<field>}}. A rule that references the user denies signed-out visitors. Field operators $in, $nin, $ne and $all work in rules too.

Defaults

Without rls: create and read are open; update and delete require the creator. Anonymous records can then only be changed by admins.

Who bypasses rules

• App users with the admin role.
• Backend functions using the service client.
• You, in the dashboard.

Patterns

// Private to each user
"rls": { "create": true, "read": { "created_by": "{{user.email}}" }, "update": { "created_by": "{{user.email}}" }, "delete": { "created_by": "{{user.email}}" } }

// Public form, admin-only inbox
"rls": { "create": true, "read": { "user_condition": { "role": "admin" } }, "update": false, "delete": { "user_condition": { "role": "admin" } } }

// Published or own drafts
"rls": { "read": { "$or": [ { "data.published": true }, { "created_by": "{{user.email}}" } ] } }

Field-level rules

fls maps a field name to optional read and write rules, written the same way as rls. A field that fails its read rule is removed from every response (list, filter, get, create and update results) and is ignored by filters. Setting a field that fails its write rule returns 403. Admins and the service key always pass. The system field created_by can be protected too.

"fls": {
  "phone": { "read": { "created_by": "{{user.email}}" } },
  "approved": { "write": { "user_condition": { "role": "admin" } } }
}