Security Review Skill
A security review is a focused pass for the ways a change could be abused — before it reaches production.
This skill reviews a design, PR, or feature against the recurring risk areas, ranks findings by severity, and
gives a clear verdict with concrete fixes. It's for code/systems you own or are authorized to review, and it
complements (not replaces) automated scanners and a formal pentest.
Required Inputs
Ask for these only if they aren't already provided:
- What's under review — the design/diff/feature, and what it does.
- Context — the stack, where it runs, what data/permissions it touches, who can reach it (internet-facing? authenticated?).
- Sensitivity — the assets involved (PII, credentials, money, admin capability) and the threat context.
Output Format
Security review: [change/feature]
Summary & verdict — one-line read and a call: ✅ ship / 🔁 fix-first / ⛔ block, with the gating issue(s).
Review by risk area — scan each and note findings:
- AuthN / AuthZ — is identity verified, and is every action authorized (incl. object-level / IDOR, privilege escalation)?
- Input handling — validation/encoding; injection (SQL/command/template), SSRF, path traversal, deserialization, XSS.
- Secrets & crypto — hard-coded secrets, key handling, weak/absent crypto, tokens in logs/URLs.
- Data exposure — over-broad responses, PII in logs/errors, missing encryption in transit/at rest, verbose errors.
- Dependencies & config — known-vuln libraries, insecure defaults, missing security headers, CORS, permissions.
- Abuse & availability — rate-limiting, resource exhaustion, business-logic abuse, missing audit logging.
Findings (ranked) — each with severity, where, why it's exploitable, and the fix:
| Severity |
Area |
Finding (how it's exploited) |
Fix |
| 🔴 Critical/High |
|
|
|
| 🟡 Medium |
|
|
|
| 🔵 Low / hardening |
|
|
|
What's done well — controls already in place (so they're kept).
Follow-ups — anything needing a scanner, a pentest, or a deeper look.
Quality Checks
Anti-Patterns
Based On
Secure code/design review practice (OWASP Top 10 & ASVS risk areas, severity-ranked findings, actionable remediation).
1---2name: security-review3description: Review a design, PR, or feature for security issues before it ships. Use when asked to do a security review, security-review a change/PR, or check a feature for vulnerabilities. Produces a structured review across the common risk areas (authn/authz, input handling, secrets, data exposure, dependencies), findings ranked by severity with concrete fixes, and a ship / fix-first verdict. For code and systems you own or are authorized to review.4---5
6# Security Review Skill
7
8A security review is a focused pass for the ways a change could be abused — before it reaches production.
9This skill reviews a design, PR, or feature against the recurring risk areas, ranks findings by severity, and
10gives a clear verdict with concrete fixes. It's for code/systems you own or are authorized to review, and it
11complements (not replaces) automated scanners and a formal pentest.
12
13## Required Inputs
14
15Ask for these only if they aren't already provided:
16
17- **What's under review** — the design/diff/feature, and what it does.
18- **Context** — the stack, where it runs, what data/permissions it touches, who can reach it (internet-facing? authenticated?).
19- **Sensitivity** — the assets involved (PII, credentials, money, admin capability) and the threat context.
20
21## Output Format
22
23### Security review: [change/feature]
24
25**Summary & verdict** — one-line read and a call: ✅ ship / 🔁 fix-first / ⛔ block, with the gating issue(s).
26
27**Review by risk area** — scan each and note findings:
281. **AuthN / AuthZ** — is identity verified, and is every action authorized (incl. object-level / IDOR, privilege escalation)?
292. **Input handling** — validation/encoding; injection (SQL/command/template), SSRF, path traversal, deserialization, XSS.
303. **Secrets & crypto** — hard-coded secrets, key handling, weak/absent crypto, tokens in logs/URLs.
314. **Data exposure** — over-broad responses, PII in logs/errors, missing encryption in transit/at rest, verbose errors.
325. **Dependencies & config** — known-vuln libraries, insecure defaults, missing security headers, CORS, permissions.
336. **Abuse & availability** — rate-limiting, resource exhaustion, business-logic abuse, missing audit logging.
34
35**Findings (ranked)** — each with severity, where, why it's exploitable, and the fix:
36
37| Severity | Area | Finding (how it's exploited) | Fix |
38|---|---|---|---|
39| 🔴 Critical/High | | | |
40| 🟡 Medium | | | |
41| 🔵 Low / hardening | | | |
42
43**What's done well** — controls already in place (so they're kept).
44
45**Follow-ups** — anything needing a scanner, a pentest, or a deeper look.
46
47## Quality Checks
48
49- [ ] Every standard risk area is considered (authz incl. IDOR, input/injection, secrets, data exposure, deps, abuse)
50- [ ] Findings are ranked by severity with a concrete, actionable fix each
51- [ ] Exploitability is explained — why it's a real issue in this context, not a generic warning
52- [ ] A clear ship / fix-first / block verdict names the gating issues
53- [ ] Existing good controls are acknowledged; deeper follow-ups (scanner/pentest) are flagged
54
55## Anti-Patterns
56
57- [ ] Do not produce a generic checklist — tie each finding to this code/design and its exploit path
58- [ ] Do not rank everything the same — separate critical from hardening nits
59- [ ] Do not report an issue without a fix — give the concrete remediation
60- [ ] Do not miss authorization (IDOR/privilege) — it's the most common real-world web flaw
61- [ ] Do not review code you don't own or aren't authorized to assess
62
63## Based On
64
65Secure code/design review practice (OWASP Top 10 & ASVS risk areas, severity-ranked findings, actionable remediation).