Security Code Review

The Problem

Security vulnerabilities hide in plain sight. A developer writes innerHTML = userInput without thinking twice. An API endpoint skips authorization checks because “it’s internal.” A JWT secret gets committed in a config file. Standard code reviews catch style issues but systematically miss these attack vectors because reviewers lack a security-first mental model. One missed vulnerability can expose your entire user base.

The Prompt

Perform a security-focused code review on the following code. Act as a penetration tester reviewing source code before a security audit.

LANGUAGE/FRAMEWORK: [e.g., TypeScript/Next.js, Python/Django, Java/Spring]
DEPLOYMENT: [e.g., public API, internal dashboard, mobile backend]

CODE:
[paste your code here]

Analyze against the OWASP Top 10 (2021) plus these additional vectors:

1. **Injection** (SQL, NoSQL, OS command, LDAP)
   - Is user input ever concatenated into queries or commands?
   - Are parameterized queries/prepared statements used consistently?

2. **Broken Authentication**
   - Are passwords hashed with bcrypt/argon2 (not MD5/SHA)?
   - Is session management secure (httpOnly, secure, sameSite cookies)?
   - Are rate limits applied to login/reset endpoints?

3. **Sensitive Data Exposure**
   - Are secrets hardcoded or logged?
   - Is PII encrypted at rest and in transit?
   - Do error messages leak stack traces or internal paths?

4. **XSS (Cross-Site Scripting)**
   - Is user input sanitized before rendering in HTML?
   - Are dangerouslySetInnerHTML / v-html / innerHTML used with untrusted data?
   - Are CSP headers configured?

5. **CSRF (Cross-Site Request Forgery)**
   - Are state-changing endpoints protected with CSRF tokens?
   - Is SameSite cookie attribute set?

6. **Broken Access Control**
   - Can users access resources belonging to other users (IDOR)?
   - Are admin endpoints protected beyond just hiding the UI?
   - Is authorization checked at the data layer, not just the route layer?

7. **Security Misconfiguration**
   - Are debug modes, default credentials, or verbose errors exposed?
   - Are CORS headers overly permissive (origin: *)?
   - Are security headers set (X-Frame-Options, HSTS, CSP)?

8. **Supply Chain**
   - Are dependencies pinned to exact versions?
   - Do any packages have known CVEs?

For each vulnerability found, provide:
- **CWE ID**: The Common Weakness Enumeration identifier
- **Severity**: critical / high / medium / low
- **Attack Vector**: How an attacker would exploit this
- **Proof of Concept**: Example malicious input
- **Fix**: Secure code replacement

Example Output

## Security Review: 4 vulnerabilities found

### CRITICAL — CWE-89: SQL Injection
Location: src/api/users.ts:47
Code: `db.query("SELECT * FROM users WHERE email = '" + req.body.email + "'")`
Attack Vector: Attacker sends email: `' OR '1'='1' --`
PoC: curl -X POST /api/users -d '{"email": "' OR 1=1 --"}'
Fix:
  db.query("SELECT * FROM users WHERE email = $1", [req.body.email])

### HIGH — CWE-79: Stored XSS
Location: src/components/Comment.tsx:12
Code: `<div dangerouslySetInnerHTML={{ __html: comment.body }} />`
Attack Vector: User submits comment: `<img src=x onerror=alert(document.cookie)>`
Fix: Use DOMPurify: `<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(comment.body) }} />`

### MEDIUM — CWE-352: Missing CSRF Protection
Location: src/api/settings.ts (all POST endpoints)
Fix: Add CSRF middleware: `app.use(csrf({ cookie: { httpOnly: true, sameSite: 'strict' } }))`

### LOW — CWE-200: Verbose Error in Production
Location: src/middleware/error.ts:8
Code: `res.json({ error: err.message, stack: err.stack })`
Fix: `res.json({ error: isProduction ? 'Internal error' : err.message })`

When to Use

Run this on every pull request that touches authentication, authorization, user input handling, or API endpoints. Essential before deploying any public-facing service, processing payments, or handling PII. Use it as a security gate in your review workflow — the cost of finding a vulnerability before production is orders of magnitude less than after.

Pro Tips

• Provide deployment context — “public API with 50k users” triggers different severity assessments than “internal admin tool behind VPN.”
• Chain with dependency audit — after reviewing your code, ask “Now audit the package.json for known CVEs and risky dependencies.”
• Request a threat model — follow up with “Based on this code, what are the top 3 attack scenarios an adversary would attempt?”
• Test the fixes — ask “Generate curl commands I can use to verify each vulnerability is patched.”