Skip to content
Documentation
Skill

/secure-code-review

Systematically reviews code for SQL injection, XSS, SSRF, broken access control, cryptographic failures, and other common OWASP Top 10 vulnerabilities, providing vulnerable code examples and ready-to-use remediation guidance. Trigger this skill when users ask for a security

From plugin
claude-code-guide
4.5k79 skills109 agents
Install
$ npx -y skills add zebbern/claude-code-guide --skill secure-code-review --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/secure-code-review

Context preview

The summary Claude sees to decide when to auto-load this skill.

Systematically reviews code for SQL injection, XSS, SSRF, broken access control, cryptographic failures, and other common OWASP Top 10 vulnerabilities, providing vulnerable code examples and ready-to-use remediation guidance. Trigger this skill when users ask for a security

SKILL.md

secure-code-review.SKILL.md
name: secure-code-review
description: "Systematically reviews code for SQL injection, XSS, SSRF, broken access control, cryptographic failures, and other common OWASP Top 10 vulnerabilities, providing vulnerable code examples and ready-to-use remediation guidance. Trigger this skill when users ask for a security review, vulnerability scan, or penetration testing assistance, or mention keywords like OWASP, SQL injection, XSS, code audit, or security checklist."
license: MIT

OWASP Top 10 Code Security Review Checklist

A systematic security review based on the OWASP Top 10 (2021) standard. Each item includes: vulnerability description, typical vulnerable code, inspection checkpoints, and remediation examples. Designed for security-focused code review of web applications.

Usage

Provide the code files or code snippets to review, and specify which OWASP categories to check (or request a full review) to receive an item-by-item audit report.

**Example prompts:**

  • "Check this code for SQL injection risks"
  • "Run a full OWASP Top 10 security review on this project"
  • "Does this API endpoint have any SSRF vulnerabilities?"

---

Quick Reference

| ID | Category | Key Check | |----|----------|-----------| | A01 | Broken Access Control | Does every endpoint verify the current user's identity? Can users access others' data by changing IDs? | | A02 | Cryptographic Failures | Are passwords hashed with bcrypt/argon2? Are secrets hardcoded? | | A03 | Injection | String-concatenated SQL? `shell=True`? Unescaped template output? | | A04 | Insecure Design | Is rate limiting in place? Can critical workflows be bypassed? | | A05 | Security Misconfiguration | DEBUG enabled? Stack traces in error pages? Default credentials? | | A06 | Vulnerable Components | Any CVEs from `pip audit` / `npm audit`? | | A07 | Authentication Failures | Is JWT signature verified? Can tokens be revoked? Is MFA available? | | A08 | Integrity Failures | Any `pickle.loads` deserializing untrusted data? | | A09 | Logging & Monitoring Failures | Are plaintext passwords in logs? Are failed logins recorded? | | A10 | SSRF | Are user-supplied URLs filtered against internal IPs? |

---

Review Process SOP

**Core principle: prefer false positives over missed true positives.**

1. **Define scope** — Identify the files, modules, or code snippets to review 2. **Full coverage check** — Scan through A01-A10 sequentially. **Every item must appear in the report** (mark items with no findings as pass). The default behavior is to only report issues found — this process requires full coverage to ensure nothing is missed 3. **Risk classification** — Label each finding:

  • RED High: Directly exploitable (RCE, SQL injection, SSRF reaching internal networks, plaintext password storage)
  • YELLOW Medium: Exploitable under specific conditions (missing rate limiting, weak password policy, static tokens)
  • GREEN Low: Defense-in-depth gap with no direct exploitation path (missing security headers, insufficient logging)

4. **Every finding must include ready-to-use fix code** (actual code, not just a description). Reference specific `file:line_number` 5. **Output the review report** — Use the template below, findings sorted by severity descending, with a prioritized remediation list at the end

---

A01:2021 — Broken Access Control

**Risk:** Users can access other users' data or perform unauthorized operations.

**Checkpoints:**

  • [ ] Does every API endpoint enforce authorization?
  • [ ] Are there IDOR vulnerabilities (Insecure Direct Object References) — can users access others' data by modifying ID parameters?
  • [ ] Do admin interfaces verify roles?
  • [ ] Is access control enforced server-side (not just by hiding UI elements)?
  • [ ] Is the CORS policy overly permissive?

Vulnerable Code Example

# ❌ Vulnerable: No authorization check — any user can view others' orders by changing user_id
@app.route("/api/orders/<user_id>")
def get_orders(user_id):
    orders = db.query(f"SELECT * FROM orders WHERE user_id = {user_id}")
    return jsonify(orders)

Remediation Example

# ✅ Fixed: Verify the authenticated user can only access their own data
@app.route("/api/orders")
@login_required
def get_orders():
    current_user_id = get_current_user().id
    orders = db.query("SELECT * FROM orders WHERE user_id = %s", (current_user_id,))
    return jsonify(orders)

---

A02:2021 — Cryptographic Failures

**Risk:** Sensitive data (passwords, credit card numbers, personal information) is unencrypted or uses weak cryptographic algorithms.

**Checkpoints:**

  • [ ] Are passwords stored using secure hashing (bcrypt/scrypt/argon2) rather than MD5/SHA1?
  • [ ] Is HTTPS enforced for sensitive data in transit?
  • [ ] Are encryption keys hardcoded in the source code?
  • [ ] Are deprecated cryptographic algorithms in use (DES, RC4, MD5)?
  • [ ] Are sensitive database fields encrypted at rest?

Vulnerable Code Example

# ❌ Vulnerable: MD5 for password storage, hardcoded secret key
import hashlib

SECRET_KEY = "my-secret-key-123"

def save_password(password):
    hashed = hashlib.md5(password.encode()).hexdigest()
    db.save(hashed)

Remediation Example

# ✅ Fixed: bcrypt for password hashing, secret key from environment variable
import bcrypt
import os

SECRET_KEY = os.environ["SECRET_KEY"]

def save_password(password):
    salt = bcrypt.gensalt()
    hashed = bcrypt.hashpw(password.encode(), salt)
    db.save(hashed)

---

A03:2021 — Injection

**Risk:** User input is concatenated directly into SQL, OS commands, LDAP queries, etc., allowing attackers to execute arbitrary queries or commands.

**Checkpoints:**

  • [ ] Do SQL queries use parameterized queries / ORM (not string concatenation)?
  • [ ] Are there `os.system()` or `subprocess.call(shell=True)` calls that concatenate user input?
  • [ ] Does template rendering properly escape user input (preventing XSS)?
  • [ ] Are special char
Read more
Ships withclaude-code-guide

Claude Code Guide - Setup, Commands, workflows, agents, skills & tips-n-tricks from beginner to power user!

Get the whole plugin

Other skills on claude-code-guide.