← ClaudeAtlas

code-security-reviewlisted

Review code for real security vulnerabilities — injection, auth/authz bypass, insecure deserialization, secret handling, SSRF, path traversal, XSS, insecure direct object references. Use when the user asks for a security review, mentions a vulnerability class by name, or when touching auth, input parsing, file paths, external requests, or serialization.
oliver-chase/OliverCode · ★ 0 · Code & Development · score 70
Install: claude install-skill oliver-chase/OliverCode
# Security Review A procedural checklist for finding real, exploitable vulnerabilities — not a restatement of "don't hardcode secrets." Pre-commit hooks already catch secrets/PII mechanically (`.githooks/pre-commit` Gate 1); this skill covers what a mechanical gate can't: judgment calls about how untrusted input flows through the system. ## Process ### Phase 1 — Map Trust Boundaries Before looking for specific bugs, identify where untrusted data enters the system: - User input (form fields, query params, request bodies, headers, cookies) - File uploads and their declared vs. actual content type - Data from third-party APIs or webhooks (even "trusted" partners can be compromised or send malformed data) - Data read back from a database that another, less-trusted code path wrote Everything downstream of these boundaries is suspect until validated. Everything upstream (internal config, code constants) is not the target of this review. ### Phase 2 — Walk Each Vulnerability Class Against the Boundaries Found For each trust boundary from Phase 1, check the vulnerability classes that apply to how that data is used: | Class | Look for | Concrete check | |---|---|---| | Injection (SQL/NoSQL/command/template) | User input concatenated into a query, shell command, or template string | `grep` for string concatenation or f-strings feeding into `execute(`, `exec(`, `spawn(`, template render calls — the fix is parameterized queries / escaped templating, never a blocklist | | Auth byp