security-audit-methodology

Audit Phases

Every audit follows this sequence. Don't skip phases — each informs the next.

1. Reconnaissance

Map the attack surface before testing anything.

• Inventory endpoints: every route, API path, WebSocket, webhook
• Identify trust boundaries: where does user input enter? Where does data cross services?
• Map authentication flows: login, registration, password reset, token refresh, MFA
• Catalog data stores: what's stored where, what's sensitive, what's encrypted
• Review dependencies: check package-lock.json, Gemfile.lock, requirements.txt against known CVEs

Output: attack surface map — a list of entry points ranked by exposure.

2. Threat Modeling

For each trust boundary, ask: "What could an attacker do here?"

STRIDE per boundary:

| Threat | Question | |--------|----------| | Spoofing | Can someone pretend to be another user/service? | | Tampering | Can data be modified in transit or at rest? | | Repudiation | Can actions be performed without audit trail? | | Information Disclosure | Can sensitive data leak through errors, logs, or side channels? | | Denial of Service | Can this endpoint be abused to exhaust resources? | | Elevation of Privilege | Can a normal user reach admin functionality? |

Prioritize by: exploitability (how easy) x impact (how bad).

3. Testing

Test each threat systematically. Order matters — start with auth, then access control, then input handling.

Auth testing sequence:

1. Can I access protected routes without a token?
2. Can I use an expired/revoked token?
3. Can I escalate from user to admin?
4. Can I enumerate valid usernames?
5. Is there rate limiting on login?

Input handling sequence:

1. Test every user input for injection (SQL, command, template, LDAP)
2. Test file uploads for type bypass, path traversal, oversized files
3. Test redirects for open redirect / SSRF
4. Test serialization endpoints for insecure deserialization

Data exposure sequence:

1. Check error messages for stack traces, internal paths, DB details
2. Check logs for PII, tokens, passwords
3. Check API responses for over-fetching (fields the client doesn't need)
4. Check headers for version disclosure

4. Evidence Collection

For every finding, capture:

• Reproduction steps: exact request/response (curl, screenshot, or code)
• Impact statement: what an attacker gains (not just "XSS exists" but "attacker can steal session tokens via reflected XSS on /search")
• Affected scope: how many endpoints/users/data are at risk

5. Risk Rating

Use a consistent severity scale:

| Severity | Criteria | |----------|----------| | Critical | Remote code execution, auth bypass, mass data exposure | | High | Privilege escalation, stored XSS, SQL injection with limited scope | | Medium | CSRF on sensitive actions, information disclosure, missing rate limiting | | Low | Clickjacking, verbose errors, missing security headers | | Info | Best practice deviations, no direct exploit path |

6. Reporting

Structure findings for action, not just documentation:

## [SEVERITY] Finding Title

**Location**: endpoint/file:line
**Category**: OWASP category
**Evidence**: reproduction steps
**Impact**: what an attacker gains
**Remediation**: specific fix (not just "sanitize input" — show how)
**Verification**: how to confirm the fix works

App-Type Quick Reference

Web Application

Focus areas: auth flows, session management, CSP, CORS, cookie flags, XSS, CSRF

REST API

Focus areas: BOLA (broken object-level auth), mass assignment, rate limiting, input validation on all fields, JWT handling

CLI Tool

Focus areas: command injection via arguments, environment variable trust, file path traversal, privilege of executed commands

Library/Package

Focus areas: dependency chain, input validation at public API boundary, no secrets in source, safe defaults

Common Audit Anti-Patterns

What auditors miss:

• Testing only the happy path: auth bypass often lives in edge cases (password reset, OAuth callback, token refresh)
• Ignoring business logic: technical vulnerabilities get attention, but "can a user buy something for $0?" is often worse
• Skipping second-order effects: input stored now, rendered later (stored XSS), or data crossing service boundaries unsanitized
• Over-relying on automated scanners: scanners find low-hanging fruit. Manual testing finds the real problems.
• Not testing as different roles: test every endpoint as unauthenticated, regular user, and admin