Security Audit Skill

Specialized review for red-light scenarios involving security-critical code.

When to Use

Automatically invoke when code involves:

• Authentication or authorization
• Payment processing or billing
• Personal identifiable information (PII)
• Cryptography or encryption
• Session management
• API keys or secrets
• Data validation or sanitization
• File uploads or downloads
• Database queries with user input

Red-Light Scenario Checklist

Authentication

• No hardcoded credentials - Secrets in environment variables
• Strong password hashing - bcrypt, argon2 (not MD5, SHA1)
• Secure token storage - httpOnly cookies (not localStorage)
• Session expiry - Proper timeout and refresh
• Rate limiting - Prevent brute force attacks
• HTTPS/TLS - All auth traffic encrypted
• No custom crypto - Use established libraries
• Secure password reset - Token-based, time-limited

Authorization

• Server-side checks - Never trust client-side validation
• Principle of least privilege - Minimal permissions
• Permission checks on every request - No caching of permissions
• No exposed role structures - Internal roles not leaked to client
• Audit logging - Authorization failures logged
• No user ID trust - Validate user identity on server

Payment Processing

• PCI compliance - Using approved payment processor
• No raw card storage - Never store credit card numbers
• No CVV storage - CVV never persisted
• Idempotency - Duplicate payment prevention
• Transaction logging - All payments logged
• Webhook verification - Signature validation
• SSL/TLS required - Encrypted payment traffic
• Client amount distrust - Server validates amounts

Data Protection

• Encryption at rest - Sensitive data encrypted in database
• Encryption in transit - HTTPS/TLS for all sensitive data
• Input sanitization - All user input validated and sanitized
• Parameterized queries - No SQL injection vulnerabilities
• CSRF protection - Token-based CSRF prevention
• XSS prevention - Output encoding, CSP headers
• No secrets in logs - Sensitive data not logged
• No secrets in version control - .env files gitignored

Common Vulnerabilities

Check for these specific issues:

SQL Injection

// BAD
db.query(`SELECT * FROM users WHERE id = ${userId}`)

// GOOD
db.query('SELECT * FROM users WHERE id = ?', [userId])

XSS

// BAD
element.innerHTML = userInput

// GOOD
element.textContent = userInput

Hardcoded Secrets

// BAD
const apiKey = "sk_live_abc123"

// GOOD
const apiKey = process.env.API_KEY

Insecure Token Storage

// BAD
localStorage.setItem('token', jwt)

// GOOD
// Set httpOnly cookie on server
res.cookie('token', jwt, { httpOnly: true, secure: true })

Threat Modeling

For each security-sensitive change, document:

1. Attack Surface

• What new endpoints or functionality is exposed?
• What user input is accepted?
• What external services are called?

2. Potential Threats

• What could an attacker do with this?
• What's the worst-case scenario?
• What data could be compromised?

3. Mitigations

• What protections are in place?
• What validation is performed?
• What monitoring/logging exists?

4. Blast Radius

• How many users affected if compromised?
• What data is at risk?
• What's the recovery plan?

Output Format

## Security Audit Results

### Critical Issues (FAIL - Must Fix)
- [Issue 1]: [description]
  - Location: [file:line]
  - Threat: [what could go wrong]
  - Fix: [how to address]

### Warnings (CONCERN - Should Fix)
- [Issue 1]: [description]
  - Location: [file:line]
  - Risk: [potential problem]
  - Recommendation: [suggested improvement]

### Passed Checks
- [Check 1]: ✓ Verified
- [Check 2]: ✓ Verified

### Threat Model
- Attack Surface: [description]
- Key Threats: [list]
- Mitigations: [what's in place]
- Blast Radius: [impact if compromised]

### Recommendations
1. [Action item 1]
2. [Action item 2]

Integration with Workflow

This skill is invoked:

1. When security-related globs match (auth/, payment/)
2. During

   /review

   for security-sensitive code
3. Before committing changes to red-light zones
4. When preToolUse hook detects security scenario

Required Before Approval

For any security-critical code:

• Threat model documented
• All critical issues resolved
• Security review completed
• Rollback plan exists
• Monitoring/logging in place
• No secrets in code or logs

Common Security Anti-Patterns

Flag these immediately:

1. OAuth.js + OAuth2.js pattern - Multiple auth implementations create gaps
2. Mixed auth and business logic - Makes security audits impossible
3. Client-side permission checks only - Trivially bypassed
4. Trusting user input - Always validate and sanitize
5. Preserving legacy auth patterns - Old insecure code shouldn't be replicated

Why This Matters

Security vulnerabilities can:

• Expose user data
• Enable unauthorized access
• Process fraudulent payments
• Damage reputation
• Create legal liability

Red-light scenarios require validated plans and thorough review before implementation.