How we check who can change what

Every time something on this site changes your data — a save, an edit, a deletion — three independent checks have to pass before the change goes through. Any one of those checks failing stops the write. The point of having three is that a single bug, anywhere in the stack, does not equal a leak.

The three checks, in plain terms

The first check happens in the application code that handles your request. Before any database call, the code reads who you are signed in as and which resource you are trying to touch, then asks the database "does this resource belong to this person?" If the answer is no, the request stops there, with the attempt written to our audit log.

The second check happens at the form layer. The data you send is matched against a strict schema that lists every field you are allowed to change for this kind of request — and only those fields. Extra fields, fields you should not be able to touch, fields like "user_id" that identify other people, are rejected outright. This blocks a class of attack called over-posting, where a malicious request tries to slip in a field the form was never meant to accept.

The third check is at the database itself. Row-Level Security (RLS) policies, enforced by Postgres, make sure you can only read or write rows that are yours, or rows that have been explicitly shared with you. This is the last line of defence — the safety net if anything in the layers above failed.

Why this matters to you

A misconfigured database table will not, on its own, leak everyone's data. A bug in the form-handling code will not, on its own, let someone alter a record they don't own. A leaked service-account credential cannot silently change your record without leaving a trail. Each control has to fail before there's exposure, and each control is owned by a different layer of the system.

Who can see what on the staff side

Editorial staff operate with the smallest set of permissions their job needs. Editors cannot read your personal data. Data Protection Officer queues are visible only to the DPO. Security reports are visible only to the security responder. Administrative override exists for emergencies and is itself logged.

See also

• Audit log
• Data residency
• Security and privacy

This summary is reviewed quarterly. Last reviewed: 28 May 2026.