security-audit

Security Audit

Overview

Security vulnerabilities are invisible until exploited. This skill provides a systematic approach to finding them before attackers do.

Core principle: ASSUME BREACH. Review every input, every output, every boundary.

Iron Law:

NO SECURITY REVIEW WITHOUT THREAT MODELING FIRST

When to Use

• Before merging any authentication or authorization code
• Before shipping features that handle user data
• When adding third-party dependencies
• After environment variable / secrets changes
• Periodic security sweeps on production code
• Reviewing MCP server endpoints (especially SSE/HTTP transport)

The Four Phases

Phase 1: Threat Modeling

Before reviewing any code:

1. Identify Assets — What are we protecting? (user data, tokens, credentials, business logic)
2. Identify Attack Surfaces — HTTP endpoints, file uploads, environment vars, third-party integrations
3. Identify Threat Actors — External attackers, malicious insiders, compromised dependencies
4. Map Data Flow — Where does sensitive data enter, travel, and exit?

Phase 2: OWASP Top 10 Checklist

Work through each category systematically:

A01: Broken Access Control

- [ ] Every endpoint checks authentication
- [ ] Authorization verified per-resource, not just per-route
- [ ] IDOR: Can user A access user B's data by changing ID?
- [ ] Admin routes protected from regular users
- [ ] CORS policy restricts allowed origins

A02: Cryptographic Failures

- [ ] No plaintext passwords stored
- [ ] Sensitive data encrypted at rest (PII, tokens, keys)
- [ ] TLS enforced for all connections
- [ ] Weak algorithms absent (MD5, SHA1 for passwords, DES)
- [ ] Secrets not in code, logs, or URLs

A03: Injection

-- ❌ SQL Injection vulnerable
db.query(`SELECT * FROM users WHERE id = ${userId}`);

-- ✅ Parameterized
db.query('SELECT * FROM users WHERE id = ?', [userId]);

// ❌ Command Injection
exec(`ls ${userInput}`);

// ✅ Safe
execFile('ls', [userInput]);