The access rules live in Postgres (row-level security), not on the screen. Each table has policies stating which rows each role may see, and they are evaluated inside the database engine. Permissions are also per COLUMN: a person cannot change their own role or grant themselves permissions, because that column is not writable from the application.

If isolation lived in the screen code, one forgotten filter in one query — or a guessed URL — would be enough for one client to see another’s data. This way, even if the query were written wrongly, the database does not return those rows.

The service key lives in a server environment variable and is used in exactly one file. It never goes in a variable starting with `NEXT_PUBLIC_`, because those are baked into the bundle the browser downloads. The file holding the keys is in `.gitignore`, and the example file carries fake values.

That key bypasses EVERY security policy. Published in the browser, anyone could read and delete the entire database. It is the most common serious flaw in real projects and the easiest to commit: mistyping one variable name is enough.

Every form has a schema defining the shape, type and length of each field, and it is checked ON THE SERVER. Browser validation exists to be kind to whoever is typing; the one that decides is the server’s, because the browser’s is bypassed in three clicks. Queries always use parameters: a query is never assembled by gluing text together.

Without server-side validation, anyone can send a direct request containing anything. And without parameterised queries, a string like `' OR 1=1 --` would stop being a string and become part of the query: that is plain old SQL injection.

The counter lives in the database, not in server memory: that way it still holds even when the server is running as several copies at once. Each form has its own limit, and the ones that matter most — signing in, registering — fail closed if the control itself breaks, rather than letting requests through. What a signed-in client uploads is counted per account rather than per IP, so one person’s excess never stops someone else on the same network from paying.

Without a limit, trying the thousand most common passwords against an account is a matter of seconds. With it, it takes over a day. It does not make the attack impossible: it makes it slow enough to stop being worth it.

Type and size are checked, and the real content of the file — its first bytes — is inspected rather than trusting the extension in its name. Payment proofs and contracts go to PRIVATE storage: they are read through a temporary link that expires, not a public address that can be shared or guessed.

Renaming `program.exe` to `proof.jpg` is trivial. And if proofs sat at a public address, changing one number in the URL would be enough to see another client’s.

They are sent on every response from the project configuration: no framing the site, no content-type guessing, control over what is sent when leaving the site, and the content policy. Private pages additionally carry the instruction not to be cached.

Without the first, another site can place ours in an invisible frame so that someone who thinks they are clicking their button clicks ours. Without the caching one, somebody’s panel can stay stored in the browser of a shared computer.