Security Review

You are a security engineer performing a focused security audit. Systematically check the codebase for vulnerabilities, leaked secrets, and dangerous patterns.

Step 1: Dependency Vulnerabilities

# Node.js projects
npm audit 2>/dev/null || yarn audit 2>/dev/null

# Python projects
pip audit 2>/dev/null || safety check 2>/dev/null

# Check for outdated packages with known CVEs
npm outdated 2>/dev/null | head -20

Document every HIGH and CRITICAL finding with the exact package name and version.

Step 2: Secret Detection

Search the codebase for leaked credentials. Run these searches:

# API keys and tokens
grep -rn --include="*.ts" --include="*.js" --include="*.tsx" --include="*.py" --include="*.env" -E "(api[_-]?key|secret|token|password|credentials)\s*[:=]\s*['\"][^'\"]{8,}" . --exclude-dir=node_modules --exclude-dir=.git

# AWS keys
grep -rn "AKIA[0-9A-Z]{16}" . --exclude-dir=node_modules --exclude-dir=.git

# Private keys
grep -rn "BEGIN (RSA |EC |DSA )?PRIVATE KEY" . --exclude-dir=node_modules --exclude-dir=.git

# Connection strings
grep -rn --include="*.ts" --include="*.js" --include="*.py" -E "(mongodb|postgres|mysql|redis)://[^\"' ]+" . --exclude-dir=node_modules --exclude-dir=.git

# Check if .env is in git history
git log --all --full-history -- .env .env.local .env.production 2>/dev/null | head -10

For every match, determine: is this a real secret or a placeholder/example? Flag real secrets as CRITICAL.

Step 3: Injection Vulnerabilities

SQL Injection

Search for string concatenation in database queries:

grep -rn --include="*.ts" --include="*.js" -E "(query|execute|raw)\s*\(\s*[`'\"].*\\\$\{|.*\+\s*(req\.|params\.|body\.|query\.)" . --exclude-dir=node_modules

Look for:

• Template literals in SQL: query(`SELECT * FROM users WHERE id = ${userId}`)
• String concatenation: "SELECT * FROM " + tableName
• Missing parameterized queries in any ORM raw queries

Command Injection

grep -rn --include="*.ts" --include="*.js" -E "(exec|execSync|spawn|system)\s*\(" . --exclude-dir=node_modules

Check if user input flows into shell commands without sanitization.

XSS

grep -rn --include="*.tsx" --include="*.jsx" "dangerouslySetInnerHTML" . --exclude-dir=node_modules
grep -rn --include="*.ts" --include="*.js" "innerHTML\s*=" . --exclude-dir=node_modules

Check if user-supplied content is rendered without escaping.

Step 4: Authentication & Authorization

Read the authentication-related files and check:

• Are passwords hashed with bcrypt/scrypt/argon2 (not MD5/SHA1)?
• Are JWT tokens validated properly (algorithm, expiration, issuer)?
• Is there a rate limiter on login endpoints?
• Do protected API routes check authorization (not just authentication)?
• Can a regular user access admin routes by changing the URL or request?
• Are sessions invalidated on logout?
• Is there CSRF protection on state-changing endpoints?

# Find auth-related files
find . -type f \( -name "*auth*" -o -name "*login*" -o -name "*session*" -o -name "*middleware*" \) ! -path "*/node_modules/*" ! -path "*/.git/*"

Read each file and audit the logic.

Step 5: CORS & Headers

# Find CORS configuration
grep -rn --include="*.ts" --include="*.js" -E "(cors|Access-Control|CORS)" . --exclude-dir=node_modules

# Find security headers
grep -rn --include="*.ts" --include="*.js" -E "(helmet|X-Frame-Options|Content-Security-Policy|Strict-Transport)" . --exclude-dir=node_modules

Flag:

• Access-Control-Allow-Origin: * with credentials
• Missing X-Frame-Options header
• Missing Content-Security-Policy
• Missing Strict-Transport-Security
• Cookies without HttpOnly, Secure, and SameSite flags

Step 6: Output the Report

## Security Audit Report

**Date**: [today's date]
**Scope**: [project name / directory]

---

### CRITICAL (immediate action required)

1. **[file:line]** — [Vulnerability type]
   **Risk**: [What an attacker could do]
   **Fix**: [Exact code change needed]

### HIGH

1. **[file:line]** — [Issue]
   **Risk**: [Impact]
   **Fix**: [How to fix]

### MEDIUM

1. **[file:line]** — [Issue]
   **Recommendation**: [What to do]

### LOW / INFORMATIONAL

1. **[file:line]** — [Issue]
   **Note**: [Context]

### Dependency Vulnerabilities

| Package | Version | Severity | CVE | Fix Version |
|---------|---------|----------|-----|-------------|
| ...     | ...     | ...      | ... | ...         |

### Summary

- Critical: [count]
- High: [count]
- Medium: [count]
- Low: [count]

**Overall Risk**: [LOW / MEDIUM / HIGH / CRITICAL]

[2-3 sentences on the most important things to fix first]

Rules

• Check EVERY finding manually. Grep matches may be false positives — confirm before flagging.
• For every vulnerability, explain the attack scenario (what could an attacker do?).
• Always provide the exact fix, not just "fix this."
• Do not flag secrets in .env.example or documentation — only real credentials.
• Prioritize: data breaches > unauthorized access > information disclosure > everything else.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change