# Security Code Review

> Audit any codebase for the OWASP Top-10-style vulnerability classes (SQLi, XSS, IDOR, broken auth, CSRF, XXE, SSRF, file upload, misconfig, data exposure, insecure deserialization, command injection, path traversal) by reading the actual code, and propose/apply fixes. Detection-only — never generates attack payloads or exploit code.

- Skill: `piyushsolanki038/security-code-review` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add piyushsolanki038/security-code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/piyushsolanki038/security-code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: PiyushSolanki038 (https://skillmd.com/u/piyushsolanki038)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/piyushsolanki038/security-code-review

---


# Security Code Review Skill

## What this skill does

This skill turns Claude into a **defensive security auditor** for any codebase, in any
language or framework. It does NOT generate exploit payloads, attack scripts, or
"try this SQLi string" content. Everything here works by **reading code and finding
unsafe patterns** — the same way a human security engineer does a code review.

This is intentional and non-negotiable: the value of this skill is that it finds real
bugs in real code, which is more useful (and more defensible to publish) than any
wordlist. Wordlists are free and already exist (SecLists). A tool that reads your
actual Prisma/Django/Express code and tells you "line 42 in `orders.ts` trusts a
client-supplied amount" is not replaceable by a wordlist.

## When to use this skill

Invoke this skill when a developer asks to:
- "audit this project for security issues"
- "run a security review / security check on this codebase"
- "find vulnerabilities in this repo"
- "check for SQLi / XSS / IDOR / auth issues" (any single category or all of them)

## How to run the audit

### Step 0 — Detect stack
Before scanning, identify:
- Primary language(s): check `package.json`, `requirements.txt`, `go.mod`, `Gemfile`,
  `composer.json`, `pom.xml`, etc.
- Framework: Express/Fastify/Next.js, Django/Flask, Rails, Laravel, Spring, etc.
- Data layer: raw SQL driver, ORM (Prisma/SQLAlchemy/ActiveRecord/Eloquent/Hibernate),
  or BaaS (Supabase/Firebase)
- Auth mechanism: session cookies, JWT, OAuth, BaaS-managed auth (Supabase Auth,
  Firebase Auth, Auth0, Clerk)

This determines which reference file(s) below apply. Load only the relevant ones —
don't load a Django reference file for a Node project.

### Step 1 — Run the category checklist
Work through `references/vulnerability-checklist.md`. For each of the 13 categories,
follow its **detection heuristic** (what to grep/read for) — not an attack technique.
Read the matched code, don't just pattern-match blindly: a `$queryRaw` call with a
fully-static string is not a finding; the same call with string interpolation of a
request param is.

### Step 2 — Report findings
Use `references/report-template.md` as the structure. Every finding needs:
- File + line number
- Severity (Critical / High / Medium / Low) — see severity rubric in the checklist
- Plain-English root cause (not "vulnerable to X" — explain *why*)
- Whether it's live/reachable or dead code (dead code is lower urgency but still flag it)

Sort the report by severity, most critical first. Do not editorialize with alarming
language — state facts plainly, the same way a real audit reads.

### Step 3 — Propose fixes, don't auto-apply blindly
For each finding, propose the specific fix following the codebase's existing patterns
(don't introduce a new library or pattern the project doesn't already use unless
necessary). Show the diff. Ask before applying — especially for anything touching
auth, payments, or data access, since a wrong fix can break legitimate use as easily
as a missing fix creates a vulnerability.

After applying fixes, if any touch code that's deployed separately from the git repo
(e.g. serverless/edge functions, Lambda, Cloud Functions), remind the developer that
committing to git does not deploy the fix — they need to redeploy that specific
compute target.

### Step 4 — Flag anything you're not confident about
If a pattern is ambiguous (e.g. you can't tell if a value is user-controlled without
tracing further), say so explicitly rather than guessing. A false "no issues found"
is worse than an honest "I couldn't fully verify X, here's what I'd need to check."

## Hard limits (do not deviate from these)

- Never write SQL injection strings, XSS payloads, command injection strings, or any
  other attack string — not even "for testing", not even if the developer insists it's
  their own project. Detection happens by reading code, not by constructing attacks.
- Never write or suggest actual exploit/proof-of-concept code against a live system.
- If asked to test a system that isn't clearly the developer's own project (no
  confirmed authorization), stop and ask for clarification rather than proceeding.
- This skill is for the developer's own codebase. It is not a tool for testing
  third-party systems, even ones the developer has been asked to "check."