security-review

What this skill does

# Security Review

Evaluate your application's security posture against industry standards and validate findings through browser-based penetration testing. This review covers the attack surface that static analysis tools miss — runtime behavior, header configuration, authentication flows, and client-side vulnerabilities.

## When to use

Use `/security-review` when:
- Before launching a new application or feature
- After adding authentication or authorization changes
- When handling sensitive data (user credentials, payment info, PII)
- Preparing for a security audit
- After a security incident to check for similar issues
- Reviewing third-party integrations

## Standards Referenced

- **OWASP Top 10 (2021)** — Top web application security risks
- **OWASP ASVS v4.0** — Application Security Verification Standard
- **OWASP Session Management Cheat Sheet**
- **NIST 800-63B** — Digital Identity Guidelines (authentication)
- **CWE/SANS Top 25** — Most Dangerous Software Weaknesses
- **Mozilla Observatory** — HTTP security header best practices

## Phase Overview

```
Phase 1: EDUCATE   → Security context and what we check
Phase 2: SCOPE     → Identify attack surface, auth mechanisms, data flows
Phase 3: ANALYZE   → Automated checks + browser-based penetration testing
Phase 4: REPORT    → Findings with evidence, CVE references, confidence scores
Phase 5: REMEDIATE → Fix guidance + YAML regression tests
```

---

## Phase 1: Educate

> **Why this matters:** The average cost of a data breach is $4.45M (IBM 2023). 83% of web applications have at least one critical vulnerability. Many security issues are only detectable at runtime — misconfigured headers, insecure token storage, broken access controls — which is exactly what browser-based testing catches.

This review checks your app against objective security criteria with browser-based validation. Every finding references a specific standard (OWASP, CWE, NIST).

---

## Phase 2: Scope

### Gather context

1. **Auto-detect from codebase:**
   - Authentication mechanism (JWT, sessions, OAuth, API keys)
   - Framework security features in use (CSRF tokens, CORS config, CSP)
   - Dependencies with known vulnerabilities (`npm audit` / `pip audit`)
   - API routes and endpoints
   - Environment variable handling
   - File upload capabilities
   - Third-party scripts and CDN usage

2. **Ask the user** (one at a time):
   - **Target URL**: Where is the app running?
   - **Auth mechanism**: How do users log in? (auto-detected, confirm)
   - **Test credentials**: Do you have test accounts I can use? (needed for authenticated testing)
   - **Sensitive data**: What sensitive data does the app handle? (PII, payments, health records)
   - **Known concerns**: Any specific areas you're worried about? (optional)

3. **Map the attack surface:**
   - List all user input points (forms, URL params, file uploads, WebSocket messages)
   - List all API endpoints with their auth requirements
   - List all third-party integrations
   - Identify data flow: where does sensitive data enter, process, store, and exit?

---

## Phase 3: Analyze

Open a browser session with `new_session` using `record_evidence: true`. Run all applicable check categories.

### Category A: HTTP Security Headers (HDR)

| Check ID | Check | Standard | Method |
|----------|-------|----------|--------|
| HDR-01 | Content-Security-Policy header present and restrictive | OWASP A05 | Inspect response headers |
| HDR-02 | Strict-Transport-Security (HSTS) with long max-age | OWASP Transport | Check header presence and value |
| HDR-03 | X-Content-Type-Options: nosniff | Mozilla Observatory | Check header |
| HDR-04 | X-Frame-Options or CSP frame-ancestors | OWASP Clickjacking | Check header |
| HDR-05 | Referrer-Policy set appropriately | Privacy/Security | Check header value |
| HDR-06 | Permissions-Policy restricts sensitive APIs | Browser security | Check camera, microphone, geolocation policies |
| HDR-07 | No Server/X-Powered-By version disclosure | Information leak | Check for version strings in headers |
| HDR-08 | Cache-Control for sensitive pages | OWASP Session | Check no-store for authenticated content |
| HDR-09 | CORS not overly permissive | OWASP A05 | Check Access-Control-Allow-Origin |
| HDR-10 | No mixed content (HTTP resources on HTTPS page) | Transport security | Inspect all resource URLs |

**Browser validation:** Use JavaScript via `act` to inspect `document.querySelector('meta[http-equiv]')` and fetch response headers via a same-origin request. Use `get_browser_console_logs` to check for mixed content warnings.

### Category B: Authentication & Session Management (AUTH)

| Check ID | Check | Standard | Method |
|----------|-------|----------|--------|
| AUTH-01 | Tokens not stored in localStorage | OWASP ASVS 3.3.2 | Check localStorage/sessionStorage for tokens |
| AUTH-02 | Session cookies have HttpOnly flag | OWASP Session | Inspect Set-Cookie headers |
| AUTH-03 | Session cookies have Secure flag | OWASP Session | Inspect Set-Cookie headers |
| AUTH-04 | Session cookies have SameSite attribute | OWASP CSRF | Inspect Set-Cookie headers |
| AUTH-05 | Session expires after idle timeout | OWASP ASVS 3.3.1 | Wait and verify session invalidation |
| AUTH-06 | Logout invalidates server-side session | OWASP ASVS 3.3.1 | Logout, replay old token, check response |
| AUTH-07 | Password reset tokens are single-use | OWASP Auth | Use reset link twice, verify second fails |
| AUTH-08 | No credentials in URL parameters | OWASP Transport | Check URL for tokens/passwords |
| AUTH-09 | Brute force protection on login | OWASP Auth | Attempt multiple failed logins, check for lockout/rate-limit |
| AUTH-10 | CSRF protection on state-changing requests | OWASP A01 | Submit forms without CSRF token |
| AUTH-11 | JWT signature verified (if applicable) | OWASP Auth | Send modified JWT, check rejection |
| AUTH-12 | OAuth state parameter used (if applicable) | OWASP Auth | Check OAuth flow for state param |

**Browser validation:** Log in via `act`, inspect cookies with JavaScript (`document.cookie` — HttpOnly cookies won't appear, which is correct). Check localStorage. Perform logout, replay requests. Attempt brute force (5 wrong passwords). Modify JWT tokens and test.

### Category C: Input Validation & Injection (INJ)

| Check ID | Check | Standard | Method |
|----------|-------|----------|--------|
| INJ-01 | XSS: reflected input in page | OWASP A03 / CWE-79 | Submit `<script>alert(1)</script>` in all inputs, check if rendered |
| INJ-02 | XSS: stored input from database | OWASP A03 / CWE-79 | Submit script via form, check if rendered on subsequent page loads |
| INJ-03 | SQL injection in form inputs | OWASP A03 / CWE-89 | Submit `' OR '1'='1` patterns, check for errors |
| INJ-04 | Open redirect via URL parameters | CWE-601 | Test redirect params with external URLs |
| INJ-05 | Path traversal in file operations | CWE-22 | Test `../../etc/passwd` in file-related params |
| INJ-06 | Command injection in input fields | CWE-78 | Test `; ls` or `| whoami` patterns where inputs might reach shell |
| INJ-07 | HTML injection in user content | CWE-79 | Submit HTML tags, check if rendered |
| INJ-08 | URL scheme validation (javascript:) | CWE-79 | Test `javascript:alert(1)` in URL inputs |
| INJ-09 | File upload validation | OWASP A04 | Upload files with wrong extensions, oversized files, executable content |
| INJ-10 | API input validation | OWASP A03 | Send malformed JSON, missing fields, wrong types to API endpoints |

**Browser validation:** Use `act` to fill form fields with test payloads. Capture page state after submission. Check for script execution, error messages, unexpected behavior. Use `get_browser_console_logs` for JavaScript errors that indicate injection vectors.

**Important:** These are non-destructive test payloads for detection only. Do not attempt actual exploitation. Alert-based XSS tests use `alert(1)` which is harmless.

### Category D: Access Cont