/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
$ npx -y skills add zebbern/claude-code-guide --skill secure-code-review --agent claude-codeHow 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.mdname: 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
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
Claude Code Guide - Setup, Commands, workflows, agents, skills & tips-n-tricks from beginner to power user!
Repo: zebbern/claude-code-guide
Other skills on claude-code-guide.
- /academic-paper-reviewer
Simulates academic peer review, evaluating papers across Originality, Methodology, Results, and Writing to provide Major/Minor Revision recommendations with actionable feedback. Triggers when a user asks to \"review my paper,\" \"simulate peer review,\" or \"give my paper a peer
Open skill - /active-directory-attacks
This skill should be used when the user asks to "attack Active Directory", "exploit AD", "Kerberoasting", "DCSync", "pass-the-hash", "BloodHound enumeration", "Golden Ticket", "Silver Ticket", "AS-REP roasting", "NTLM relay", or needs guidance on Windows domain penetration
Open skill - /api-fuzzing-bug-bounty
This skill should be used when the user asks to "test API security", "fuzz APIs", "find IDOR vulnerabilities", "test REST API", "test GraphQL", "API penetration testing", "bug bounty API testing", or needs guidance on API security assessment techniques.
Open skill - /api-shape-explorer
Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".
Open skill - /audit-flow
Interactive system flow tracing across CODE, API, AUTH, DATA, NETWORK layers with SQLite persistence and Mermaid export. Use for security audits, compliance documentation, flow tracing, feature ideation, brainstorming, debugging, architecture reviews, or incident post-mortems.
Open skill - /authentication-patterns
Authentication patterns: session vs JWT vs OAuth comparison, provider selection (NextAuth, Clerk, Supabase Auth), security checklist, and common mistakes. Use when implementing auth, reviewing auth flows, or choosing auth providers.
Open skill

