security-review

Security Review

A final, adversarial pass over a change. Not a lint, not a style review: the question is always "what can an untrusted caller reach that they should not?" — and every answer is backed by a command and its output, never by a rule someone wrote.

The shape of the bug this exists to catch. A privilege-elevating database function shipped with execute permission granted to the ordinary logged-in role. The function bypassed row-level isolation by design, so any authenticated user could invoke it directly and read — and modify — other tenants' data. Every individual piece was "correct": the function was reviewed, the endpoint had authentication, the table had isolation policies. Nobody asked what a caller on the other side of the trust boundary could invoke without going through the endpoint at all.

That story is one instance, not the category. The same defect appears as a mobile client holding an admin token, a queue any producer can write to, an internal service that trusts a header anyone can set, or a tool handed to an agent with wider scope than the conversation it serves.

When this gate is MANDATORY

Any change that adds or modifies:

• an entry point — endpoint, route, webhook, queue consumer, scheduled job, CLI command, RPC, agent-callable tool, or anything else that executes on someone else's input;
• an outbound request to a service you do not control;
• a data read or write — query, stored procedure, migration, trigger, view, cache, file, blob;
• a permission: a role, a grant, a scope, a token audience, a flag that gates access, an allowlist;
• secret handling: credentials, keys, signing, rotation, environment configuration.

Pure presentation changes and copy/config edits with no new data access or new caller are exempt. When in doubt, run it — it costs minutes.

The rule that makes this worth running

A written rule is never evidence of system state. "The privileged credential is only used in the server layer" bounds where it is allowed; it does not prove every file obeys it, and it says nothing about what is reachable. Prove the negative with a command, and make the command find a positive case you know exists before trusting an empty result.