security-auditor

Purpose

Find security weaknesses in an implementation: places where user input, authentication, authorization, or sensitive data are handled unsafely, using the same categories a real security review would check.

When to Use

• Before shipping any code that handles user input, authentication, authorization, payments, or PII.
• Reviewing code that constructs queries, commands, or file paths from external input.
• The user asks for a "security review" or "security audit."

This skill is for defensive review of code you own or are authorized to review — not for developing exploits against systems you don't have permission to test.

What to Analyze

1. Injection — SQL/NoSQL/command/template injection wherever user input reaches a query, shell command, or template without parameterization/escaping.
2. Auth & session handling — password storage (hashing algorithm, salting), session token generation/expiry, missing auth checks on sensitive endpoints.
3. Access control — authorization checks present per-resource (not just "is logged in" but "is logged in and allowed to access this specific resource") — look specifically for IDOR (insecure direct object reference) patterns.
4. Secrets handling — hardcoded credentials/API keys, secrets logged in plaintext, secrets committed to version control.
5. Input validation & output encoding — unvalidated input reaching sensitive sinks; unescaped output enabling XSS.
6. Unsafe deserialization — deserializing untrusted data with a mechanism that can execute code (e.g. unsafe pickle, eval, certain YAML loaders).
7. Dependency/known-CVE exposure — flag if reviewing a dependency manifest and something is a known-vulnerable version (note: verify current CVE status rather than assuming).

Output Format

• Findings grouped by severity: Critical (remote code execution, auth bypass, data exposure) → High (injection, IDOR) → Medium (weak crypto, missing rate limiting) → Low (defense-in-depth gaps).
• Each finding: what's vulnerable, the concrete attack scenario (how an attacker would actually exploit it), and the fix.
• Note explicitly if a finding requires further verification (e.g., "confirm this endpoint isn't also protected by a gateway-level check").

Avoid

• Providing working exploit payloads beyond what's needed to demonstrate the vulnerability to the code's own author for remediation.
• Flagging theoretical issues already mitigated elsewhere in the stack (e.g. a WAF, an ORM's built-in parameterization) without checking first.
• Skipping severity ranking — an unranked list of "security issues" isn't actionable.