| name | security-reflexes |
| description | Security checklists for everyday diffs — parameterize at trust boundaries, allowlist enums, per-object authorization, secrets never in logs/bundles/errors. Apply while writing any code touching user input, authn/authz, secrets, paths, URLs, subprocesses, SQL, HTML rendering, or external APIs. |
Security Reflexes
Not a pentest methodology — these are the reflexes that fire while writing ordinary code. Scan the diff you're producing against whichever sections its surfaces touch.
Input crossing a trust boundary
Any value originating from a user, client, LLM, or external system:
- Parameterize, never concatenate: SQL/queries via placeholders; shell via array-arg APIs (no string-built commands); paths via join + canonicalize + prefix check (traversal:
../).
- Validate at the boundary, by allowlist: enums/slugs mapped through a server-side whitelist — especially LLM-generated values headed into external APIs. Reject unexpected keys, not just missing ones.
- HTML: rendering user/model text as raw HTML is an XSS. Keep markdown renderers raw-HTML-off (no rehype-raw equivalents); escape by default.
- URLs the server will fetch: validate scheme+host against an allowlist (SSRF) — a user-supplied URL fetched server-side can reach internal services/metadata endpoints.
AuthN / AuthZ
- Every mutating endpoint: WHO is calling (authentication) and MAY they touch THIS object (authorization — ownership check on the specific row/resource, not just "is logged in").
- Never trust client-supplied identity/scope fields (user IDs, account IDs, role flags, prices, approved-params). The server derives them from the session or its own records.
- Approval flows: bind execution to a server-recorded intent; the client conveys a reference, never the parameters.
Secrets
- Secrets come from env/secret managers only — never hardcoded, never in client bundles (watch framework prefixes that expose env to the browser), never in logs (including "debug" logs of full request/response objects), never in error messages echoed to users.
- External API errors: wrap/sanitize before showing users — raw provider errors leak internal detail.
- Never ask for or accept credentials that identify a human irreversibly (private keys, seed phrases) even "just to test".
Dangerous defaults to catch in review
JSON.parse/deserialization of external input without try/catch and shape validation.- Comparing secrets with
==/=== (timing) where a constant-time compare exists — matters for tokens/signatures.
- Missing rate limiting/size caps on endpoints that do expensive work or send messages.
- CORS
* on authenticated routes; cookies without httpOnly/secure/sameSite thought.
- Temp files/predictable paths for sensitive data; world-readable perms.
When the change is security-relevant by nature
If the diff touches auth flows, crypto, session handling, or permission checks: slow down, find the existing pattern in the codebase and match it exactly (bespoke crypto/session logic is almost always the bug), and say explicitly in your report which security property you preserved and how you verified it.
Escalate, don't improvise
Discovering an existing vulnerability mid-task → report it clearly (what, where, exploitability) rather than silently fixing beyond scope or ignoring it. Destructive proof-of-concepts and exploit tooling need explicit authorization context.
