security-sweeplisted

Review the working changes (or a named set of files) for real, exploitable security problems — injection, authz gaps, secret leaks, unsafe deserialization, SSRF, path traversal, and the like — and report only findings you can justify with a concrete attack path. Use this whenever the user asks for a security review, a "security check", wants to know if a change is safe to ship, is touching auth/crypto/file-uploads/user-input/database queries, or says things like "any vulnerabilities here", "is this exploitable", "audit this endpoint". Also use before shipping code that handles untrusted input or secrets.
0xmortuex/claude-code-skills · ★ 0 · Data & Documents · score 72

Install: claude install-skill 0xmortuex/claude-code-skills

# security-sweep Security review is valuable only when it's grounded and honest. A list of theoretical "consider using HTTPS" notes trains people to ignore security review; a single well-explained "this endpoint lets any user read any other user's invoices, here's the request" prevents a breach. Aim for the second kind. Report what's actually exploitable, prove it, and stay quiet about noise. ## Scope: review the change, not the universe Default to the working diff (`git diff`, and staged changes) or the files the user names. You're evaluating *this change*, not auditing the whole codebase — that keeps the review focused and the findings relevant. If you notice a severe issue in adjacent code while reading, mention it separately, but don't turn a diff review into an open-ended audit unless asked. ## What to actually look for Walk the real risk categories, tracing untrusted input to where it does damage: - **Injection** — SQL/NoSQL built by string concatenation, shell commands from user input, `eval`/template injection. Trace: does attacker-controlled data reach an interpreter without parameterization/escaping? - **Broken authorization** — the big one, and the most missed. Does the code check that the *current user* is allowed to touch *this specific resource*, or only that they're logged in? Object-level access control (IDOR) is where real breaches live. - **Authentication & session** — missing checks, weak token handling, auth decisions on client-supplied values. - **S