Security rules

Who may read and write what, evaluated on every request.

What a rule is

A rule answers one question: may this caller perform this operation on this record? Rules are attached per collection per operation (read, create, update, delete) and are evaluated on every request — console, SDK, curl, realtime subscription alike.

Rules: one row per collection and operation, with its condition.

The conditions

Condition	Allows when
`public`	Anyone with a valid project key.
`authenticated`	The request carries a valid Flares Auth access token.
`owner`	The record's owner field equals the authenticated user's id.
`server`	The caller holds a secret key — backends only.
`never`	Nobody. Useful for append-only collections (`create` allowed, `update` never).

Identity in rules

When a request carries an Auth access token, the rule sees:

auth.user.id        the Auth user's id (usr_…)
auth.user.email     their email
auth.user.claims    the claims on the token

So sender_id == auth.user.id means "a user may only create messages as themselves" — enforced by Basket, not by your frontend's good manners.

A worked example

messages.read     authenticated
messages.create   owner   (owner field: sender_id)
messages.update   never
messages.delete   server

Signed-in users read the collection and write only their own messages; nothing edits history; only a backend deletes. How tokens reach the rule →

A collection with no rule for an operation refuses that operation. The default is closed — forgetting a rule cannot open your data.