How the security works

Why there is no database key in the browser, and what exactly is checked on every request.

There is no database key in the browser

The record tables, the user accounts and the sessions are closed to the public key — not “partly protected”, but with no policy that permits access at all. Which means: even if everything running in the browser were exposed, not one row could be read with it.

A diagram of the data path in a built app: the browser, which holds no database key, calls one gateway that every read and write passes through; the gateway checks the table's permission rule; and the query is narrowed to the rows the caller created, so only those come back.The browserAsks for data — with no database keyFrom here on — on the server, not in the browserThe gatewayEvery read and write goes through it. No second path.The ruleWho may act — and on which rowsOnly your rows come backAnother user's rowYour rowAnother user's row
There is no database key in the browser. Every read and write passes through one gateway, is checked against that table's rule, and the narrowing to the caller's own rows goes inside the query itself — so a mistake returns nothing, not somebody else's row.

Every request is checked against a rule

Every table has four rules — who reads, who creates, who updates and who deletes. The rule is checked on the server on every request, and when it is “only the creator”, the filter goes inside the query itself. A mistake returns zero rows, not somebody else's rows.

A rule the model writes that is not in the vocabulary the server knows is not saved: it is replaced with the safe default for that action. The full detail is in who sees what.

A user of one app is not a user of another

Every session is stored with the id of the app it was issued for. A token taken from one site is treated on another as anonymous — not as an error, simply as somebody who is not signed in.

Signing up to an app grants nobody the admin role. The admin role comes only from the owner's screen, or in advance in a personal invitation — because signing up is a public door, and an app is live from its first build.

Your site talks to nobody

A built site holds no secret, and its policy lets it call our server and nothing else. External information — Shabbat times, exchange rates — arrives through us rather than from it, so there is no key in the site to steal.

The sites sit on a separate domain name from the system, so code running in a built site cannot reach your account here.

What we do not tell anyone

A project's id appears in the address, which is exactly why it never grants access on its own. A request for a resource you may not touch gets “not found” rather than “not permitted” — because the second answer confirms that the resource exists.

The same principle applies to signing up: an e-mail address that is already registered gets exactly the same answer as a new one, and nothing is sent to it — otherwise the form would become an instrument for finding out who is registered with you.

Did not find your answer?Write to us