Security

Security: Audits + Threats

Assume every input is hostile and every boundary will be probed. Security work is finding where an attacker's assumptions differ from yours. This is for defensive review, hardening, and threat modeling of code you're authorized to work on.

Scope: this skill complements /security-review (diff-level review of pending changes). Use /security-review for "is this change safe to merge"; use this skill for a broader audit or when threat-modeling a feature.

Threat modeling — do this before the audit

Answer four questions for the feature/endpoint:

1. What are we protecting? (user data, money, credentials, availability)
2. Who's the adversary? (anonymous internet, authenticated-but-other-user, insider, compromised dependency)
3. Where are the trust boundaries? (client→server, server→DB, service→third-party). Every arrow crossing a boundary is where validation and authz must happen.
4. What's the worst case if this one control fails? Design so a single failure isn't catastrophic (defense in depth).

The client is never trusted. Validation, authorization, and rate limits enforced only in the browser are enforced nowhere.

Audit checklist

Authentication & authorization

• Authz on every request, server-side, checked against the authenticated user — not an id from the request body/query. The classic bug: GET /api/orders/:id returns any order because it never checks the order belongs to the caller (IDOR).
• Route through lib/auth/ for user-data access — never bypass it or hand-roll a parallel check (this is a hard project rule). A bypass is a vulnerability even if it "works".
• Verify the session/token on the server for every protected route; don't trust a client-set flag. Check expiry and revocation.
• Enforce least privilege: a user gets exactly their own data. Test the "other user" and "no user" cases explicitly.

Input handling & injection

• SQL injection: use parameterized queries / bound parameters always. Never build SQL by string-concatenating user input — not even "safe-looking" values, not even for ORDER BY. Allowlist column/sort names.
• XSS: never render unsanitized user input as HTML. In React, avoid dangerouslySetInnerHTML with user content; if unavoidable, sanitize with a vetted library.
• Validate and normalize all input at the boundary against a strict schema (type, length, range, format). Reject, don't coerce, malformed input.
• SSRF/path traversal: user-controlled URLs and file paths are attacks. Allowlist destinations; resolve and confine paths under a known root.
• Command injection: don't pass user input to a shell. If you must, use argument arrays, never string interpolation.

Secrets & sensitive data

• No secrets in code, logs, error messages, or the client bundle. In Next.js, anything not prefixed for the server leaks to the browser — keep keys server-only and out of NEXT_PUBLIC_*.
• Don't log tokens, passwords, full PII, or full card/SSN numbers. Redact at the log boundary.
• Return the minimum data the client needs. Don't ship the whole user row (password hash, internal flags, other users' data) to satisfy one field.
• Hash passwords with a slow algorithm (bcrypt/argon2); never encrypt-and-store or plaintext.

Data exposure & API surface

• Error responses shouldn't leak stack traces, SQL, or internal structure to clients. Log detail server-side, return a generic message.
• Set security headers and cookie flags: HttpOnly, Secure, SameSite on session cookies; CSRF protection on state-changing routes.
• Rate-limit auth and expensive endpoints. Enumerable sequential IDs + no rate limit = scrape-all.

Dependencies & supply chain

• Run pnpm audit and review advisories for reachable vulns; pin and update deliberately.
• New dependencies are new trust — justify them (the project requires justification in the PR body) and prefer well-maintained, minimal ones.
• Watch for typosquatting and post-install scripts on unfamiliar packages.

Reporting findings

For each issue, state: where (file:line), the vulnerability (what an attacker does), impact (what they get), severity (critical/high/med/low), and the fix. Rank by exploitability × impact — a trivially exploitable IDOR outranks a theoretical timing leak. Verify a finding is real before reporting it; a false alarm costs trust.

Boundaries

Support authorized, defensive work: audits of your own/authorized code, threat modeling, hardening, CTF, and education. Do not produce working exploits for systems you don't control, mass-targeting or DoS tooling, or evasion techniques meant to harm. When in doubt about intent, ask.