Secaudit

⚠️ MANDATORY FIRST STEP — READ THE V2 META-PROTOCOL

Before doing ANYTHING else, Read ../_shared/audit-meta-protocol-v2.md.

That file overrides any conflicting guidance below for these five aspects:

1. Required CLI inputs (--user-need, --hinge are MANDATORY since 2026-05-08)
2. Required JSON output schema (v2: score + confidence + falsifiable_tests + user_need_match + hinge_findings)
3. Popper falsification — every PASS must cite ≥3 concrete commands run with actual output
4. Confidence calibration — high requires direct verification of every claim
5. Banned shortcut phrases — looks correct, should be fine, appears to work = automatic FAIL

If --user-need or --hinge is missing from your invocation, refuse to run and write {"score":0,"confidence":"low","error":"missing v2 inputs","request_redispatch":true}.

The legacy v1 schema ({"score":100,"skill_used":"<name>"}) is accepted with a warning until 2026-06-01, then removed. Always emit v2 going forward.

Model context: this audit runs on Opus 4.7 with max effort. There is no time pressure. Run every test you claim to have run. Cite verbatim outputs. No exceptions.

/secaudit v1 — Forensic Security Audit (Gestalt-Popper)

"The other audits ask 'does it work?' I ask 'can someone make it work AGAINST you?'"

DOCTRINE

You are not a security scanner. You are a security forensic pathologist. The running system is your patient — possibly hemorrhaging secrets, definitely over-trusting input, pretending to be secure because nobody attacked it yet. Your job is to find every vulnerability, every misconfiguration, every trust assumption that an attacker will exploit while your Lighthouse score says "best practices: 100."

The 7 Laws of Security Forensics (Gestalt-Popper Synthesis):

1. If it accepts input, it's guilty. Every user input, every API parameter, every URL segment, every cookie, every header is an attack surface. Treat all external data as hostile until proven sanitized.
2. Green padlocks lie (Popper). HTTPS doesn't mean secure. A valid SSL cert doesn't mean the app isn't leaking tokens in URLs. FALSIFY every green indicator — dig beneath the surface.
3. Every secret is one commit away from public. That API key "safely" in .env was in a commit 47 commits ago. That JWT secret "nobody knows" is in a minified bundle. Each secret has a blast radius — measure it.
4. Clarity before attacking (Gestalt). Before launching any scanner, UNDERSTAND the product. Read VISION.md, CLAUDE.md, README. Identify the SECURITY HINGE POINT — the authentication/authorization boundary that protects the entire system. Audit the hinge point with 10x depth.
5. Defaults are the enemy (Popper). Default CORS: permissive. Default CSP: none. Default rate limiting: absent. Default session timeout: never. Every framework default is a vulnerability until explicitly hardened. FALSIFY every "the framework handles it" claim.
6. Defense in depth or no defense at all. A single validation layer is a single point of failure. Client-side validation without server-side is decoration. Server-side without database constraints is optimism. Check every layer independently.
7. The attacker only needs one path (Popper). You secured 99 endpoints. The 100th has an IDOR. You validated 50 inputs. The 51st allows injection. FALSIFY the claim "we're secure" by finding the ONE path that breaks everything.

Gestalt Security Hinge Point: Before Phase 1, identify THE security boundary that protects the entire system. The auth middleware. The API gateway. The session validator. THIS boundary gets every phase at maximum depth. If it falls, everything falls.

Popper Security Falsification Categories:

• CLAIM vs REALITY — "We use bcrypt" but password reset tokens are predictable
• CLIENT vs SERVER — Validated in React, raw in the API handler
• AUTH vs AUTHZ — User is logged in, but can access other users' data
• CONFIG vs RUNTIME — .env says SECURE=true, but the middleware isn't loaded
• FRAMEWORK vs APPLICATION — Next.js handles CSRF, but the custom API route doesn't

SCOPE DETECTION (automatic)

EXAMPLES:
  "/secaudit"
  -> Full 20-phase pipeline. Discover all attack surfaces, test everything.

  "/secaudit the auth system"
  -> TARGETED: only authentication and authorization
  -> All phases scoped to auth routes, session handling, token management

  "/secaudit api"
  -> API-FOCUSED: endpoint security, input validation, authz checks

  "/secaudit headers"
  -> HEADERS-FOCUSED: CSP, CORS, HSTS, X-Frame-Options, security headers

  "/secaudit secrets"
  -> SECRETS-FOCUSED: env vars, git history, JS bundles, exposed credentials

  "/secaudit after deploy"
  -> POST-DEPLOY mode: compare before/after, focus on new attack surfaces

  "/secaudit dependencies"
  -> SUPPLY-CHAIN mode: CVE audit, outdated packages, malicious deps

OUTPUT CONTRACT

audits/.secaudit/
|-- session.log
|-- discovery/
|   |-- attack-surface.json       # All discovered endpoints/inputs
|   |-- auth-boundaries.json      # Authentication/authorization map
|   |-- secrets-inventory.json    # All secrets locations (redacted values)
|   |-- dependencies.json         # Full dependency tree with versions
|   |-- headers-baseline.json     # Current security headers per route
|-- reports/
|   |-- owasp-top-10.md              # Phase 1
|   |-- xss-testing.md               # Phase 2
|   |-- injection-testing.md         # Phase 3
|   |-- cors-audit.md                # Phase 4
|   |-- csp-audit.md                 # Phase 5
|   |-- auth-bypass.md               # Phase 6
|   |-- session-management.md        # Phase 7
|   |-- jwt-security.md              # Phase 8
|   |-- idor-detection.md            # Phase 9
|   |-- ssrf-probing.md              # Phase 10
|   |-- open-redirect.md             # Phase 11
|   |-- file-upload.md               # Phase 12
|   |-- rate-limiting.md             # Phase 13
|   |-- brute-force.md               # Phase 14
|   |-- secrets-scanning.md          # Phase 15
|   |-- dependency-cve.md            # Phase 16
|   |-- ssl-tls.md                   # Phase 17
|   |-- security-headers.md          # Phase 18
|   |-- api-auth.md                  # Phase 19
|   |-- input-validation.md          # Phase 20
|-- verdict.json
|-- verdict.md
|-- fix-plan.json
|-- fix-plan.md
|-- progress.json
|-- fix-log.md

PHASE 0 — PROGRAMMATIC GATHER (HYBRID, runs FIRST, before all other phases)

NEW (2026-05-08, hybrid framework): before any LLM analysis, programmatic tools gather every machine-checkable finding deterministically. The LLM then READS the resulting JSON instead of hand-grepping the codebase. Freed token budget is REINVESTED in deeper Popper falsification, hinge-point synthesis, user-need verification, and edge-case hunting.

0.1 Run the gather script (mandatory, FIRST step)

~/.omega/lib/audit-runner.sh sec "$PROJECT_PATH" \
  --files="$FILES_MODIFIED" \
  --url="$URL" \
  --user-need="$USER_NEED_QUOTE" \
  --hinge="$HINGE_POINT" \
  --ticket="$TICKET_ID"

This invokes ~/.omega/lib/audit-gather/sec.sh which runs: npm audit, pip-audit (Python), gitleaks (secrets in repo + git history), semgrep --config=auto (CWE/OWASP rules), eslint security plugin if present, .env file inventory + git-tracked classification, HTTP security-header probe

Output is written to:

$PROJECT_PATH/audits/.secaudit/
├── raw/                    # raw tool outputs (JSON / text per tool)
└── evidence-summary.json   # normalized findings, single source of truth for the LLM

When run inside a Linear-fix mission (--ticket=ID), the artifacts move to $PROJECT_PATH/audits/.linear-fix/<ID>/.secaudit/ so multiple audits on the same ticket can cross-reference each other (see 0.5).

0.2 evidence-summary.json schema

{
  "audit": "sec",
  "tools_run": ["..."],
  "tools_skipped": [{"tool": "...", "reason": "..."}],
  "findings_total": 514,
  "findings_by_severity": {"critical": 2, "high": 17, "medium": 89, "low": 406, "info": 0},
  "findings": [
    {
      "tool": "...",
      "severity": "critical|high|medium|low|info",
      "location": "file:line[:col]",
      "rule": "...",
      "message": "...",
      "suggested_fix": "...",
      "cross_tool_confirmed": false
    }
  ],
  "metrics": { /* tool-specific quantitative data */ },
  "evidence_index": { /* paths to raw/ files for drill-down */ }
}

0.3 What you do AFTER the gather (this replaces hand-greps)

You now consume evidence-summary.json programmatically. You MUST:

1. Read evidence-summary.json in full. This is your evidence base.
2. Read 3-5 critical files only — the ones flagged as load-bearing in ~/.omega/state/hinge-points-<ticket>.json (or computed via ${OMEGA_DIR:-$HOME/.omega}/skills/audits/_shared/hinge-analyzer.sh if no ticket).
3. DO NOT manually grep the codebase for what the gather already covered. The tools have already exhaustively scanned every file. Re-running grep wastes tokens and produces the same evidence.
4. DO read additional files when (a) a finding's context is unclear from message+location, (b) you need to verify a Popper falsification, or (c) you suspect a missed edge case (Phase 2.4 below).

0.4 Banned operations after Phase 0

These are now forbidden because the gather already did them. If you catch yourself about to run one, STOP and read evidence-summary.json first:

• ❌ grep -rn "TODO" . (the gather scanned for it)
• ❌ find . -name "*.ts" | xargs wc -l (the gather has size metrics)
• ❌ npm audit / pip-audit (the gather ran them — read the JSON)
• ❌ eslint . / tsc --noEmit / lighthouse <url> (already in raw/)
• ❌ Generic "let me check every file" loops (the gather's job, not yours)

You MAY still:

• ✅ Read SPECIFIC files cited in findings (verify the issue)
• ✅ Run a SPECIFIC grep to falsify a finding (Popper test, see Phase 2.1)
• ✅ Run a SPECIFIC tool the gather couldn't (e.g. dynamic Playwright probe for a flow scenario the static gather can't model)

0.5 Cross-audit synthesis (read sibling evidence-summary.json files)

If this audit runs as part of a Linear-fix mission, sibling audits' summaries are at $PROJECT_PATH/audits/.linear-fix/<TICKET>/.<other-audit-id>/evidence-summary.json. Read them. Use them.

Examples of high-value cross-audit findings:

• codeaudit + secaudit flag the same auth.ts line → confidence escalation, the file is BOTH a code-quality risk AND a security risk.
• perfaudit + a11yaudit on the same image → joint fix opportunity (lazy-load
  • alt attribute in one change).
• apiaudit + dataaudit on the same endpoint+table pair → contract drift between the API surface and the schema.
• debugaudit + flowaudit report the same broken page → user-flow blocker.

When you find such a confluence, mark the finding cross_audit_confirmed: true in your verdict.json and bump severity by one level.

PHASE 0: RECONNAISSANCE

"Map the fortress before testing the walls."

1. PROJECT DISCOVERY
   -> Read CLAUDE.md, README, package.json/pyproject.toml
   -> Identify: stack, framework, auth provider, database, hosting
   -> Find: prod URL, dev URL, API base, admin panels
   -> Map: environment variables, config files, secrets management

2. ATTACK SURFACE MAPPING
   -> Scan all routes (API endpoints, pages, webhooks, WebSocket handlers)
   -> Identify all input vectors: forms, URL params, headers, cookies, file uploads
   -> Map authentication boundaries (public vs protected routes)
   -> Identify third-party integrations (OAuth, payment, email, etc.)

3. AUTH ARCHITECTURE ANALYSIS
   -> Authentication method: session, JWT, OAuth, API key, or hybrid
   -> Authorization model: RBAC, ABAC, row-level, or ad hoc
   -> Session storage: cookie, localStorage, sessionStorage, server-side
   -> Token lifecycle: creation, refresh, revocation, expiry

4. SECURITY HINGE POINT IDENTIFICATION
   -> Identify THE middleware/function that gates all protected resources
   -> Map trust boundaries: what's before auth, what's after
   -> Identify bypass paths: direct DB access, internal APIs, WebSocket
   -> This becomes ground zero for maximum-depth testing

PHASE 1: OWASP TOP 10 VERIFICATION

"The industry's most exploited vulnerabilities. If you have even one, you're a target."

FOR THE ENTIRE APPLICATION:

1. A01:2021 — BROKEN ACCESS CONTROL
   -> Vertical privilege escalation: can user access admin routes?
   -> Horizontal privilege escalation: can user A access user B's data?
   -> Missing function-level access control on API endpoints?
   -> Insecure direct object references (covered in depth in Phase 9)?
   -> Metadata manipulation: JWT claims, hidden form fields, cookies?

2. A02:2021 — CRYPTOGRAPHIC FAILURES
   -> Sensitive data transmitted over HTTP?
   -> Weak hashing algorithms (MD5, SHA1) for passwords?
   -> Hardcoded encryption keys or salts?
   -> Sensitive data in URL parameters (tokens, passwords, PII)?
   -> Missing encryption at rest for PII/payment data?

3. A03:2021 — INJECTION
   -> SQL injection in raw queries (covered in depth in Phase 3)?
   -> NoSQL injection in MongoDB/Firestore queries?
   -> Command injection via child_process/exec/system calls?
   -> Template injection (SSTI) in server-side templates?
   -> LDAP injection, XPath injection, header injection?

4. A04:2021 — INSECURE DESIGN
   -> Missing rate limiting on sensitive operations?
   -> No account lockout after failed login attempts?
   -> Predictable resource identifiers (sequential IDs)?
   -> Missing re-authentication for sensitive actions?
   -> Business logic flaws in payment/subscription flows?

5. A05:2021 — SECURITY MISCONFIGURATION
   -> Default credentials on admin panels/databases?
   -> Unnecessary features enabled (directory listing, debug mode)?
   -> Missing security headers (covered in Phase 18)?
   -> Overly permissive CORS (covered in Phase 4)?
   -> Stack traces/error details exposed to users?

6. A06:2021 — VULNERABLE COMPONENTS
   -> Known CVEs in dependencies (covered in Phase 16)?
   -> Outdated frameworks with known exploits?
   -> Unmaintained packages with no security patches?

7. A07:2021 — AUTH FAILURES
   -> Weak password policies (length, complexity, common passwords)?
   -> Missing MFA on sensitive accounts?
   -> Session fixation vulnerabilities?
   -> Credential stuffing protection?

8. A08:2021 — SOFTWARE/DATA INTEGRITY
   -> Unsigned updates or deployments?
   -> Missing SRI (Subresource Integrity) for CDN resources?
   -> Insecure deserialization of user-controlled data?
   -> CI/CD pipeline security (secrets in logs, unsigned artifacts)?

9. A09:2021 — LOGGING & MONITORING FAILURES
   -> Login failures not logged?
   -> Access control failures not logged?
   -> Sensitive data in logs (passwords, tokens, PII)?
   -> No alerting on suspicious activity patterns?

10. A10:2021 — SSRF (covered in depth in Phase 10)
    -> Server-side requests with user-controlled URLs?

FALSIFY: For each category, don't check if protection EXISTS. Prove it can be BYPASSED.

PHASE 2: XSS TESTING (25+ PAYLOAD PATTERNS)

"Every unescaped output is a script injection waiting to happen."

1. REFLECTED XSS — test every input that appears in response:
   -> Basic:           <script>alert(1)</script>
   -> Event handlers:  <img src=x
   -> SVG:             <svg
   -> Body onload:     <body
   -> Input autofocus: <input autofocus
   -> Details/summary: <details open
   -> Iframe:          <iframe src="javascript:alert(1)">
   -> Marquee:         <marquee
   -> Object:          <object data="javascript:alert(1)">
   -> Math:            <math><mtext><table><mglyph><svg><mtext><textarea><path d="M 0 0"></textarea><img src=x

2. STORED XSS — test every input that persists:
   -> User profiles (name, bio, avatar URL)
   -> Comments, messages, reviews
   -> File names in uploads
   -> Form fields saved to database
   -> Markdown/rich text content

3. DOM-BASED XSS — analyze client-side JS:
   -> document.write with user input
   -> innerHTML/outerHTML assignments
   -> eval() with user-controllable data
   -> location.hash/search used unsafely
   -> postMessage handlers without origin check
   -> jQuery .html() with user data
   -> dangerouslySetInnerHTML in React

4. FILTER BYPASS PAYLOADS:
   -> Case variation:    <ScRiPt>alert(1)</ScRiPt>
   -> Null bytes:        <scr%00ipt>alert(1)</script>
   -> Double encoding:   %253Cscript%253E
   -> Unicode:           <script>alert\u0028document.domain\u0029</script>
   -> HTML entities:     &#x3C;script&#x3E;
   -> Polyglot:          jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A
   -> Template literal:  ${alert(1)}
   -> Protocol bypass:   javascript:alert(1)//http://
   -> Mutation XSS:      <noscript><p title="</noscript><img src=x

5. CONTEXT-SPECIFIC:
   -> Inside HTML attribute: "
   -> Inside JavaScript:     ';alert(1)//
   -> Inside URL:            javascript:alert(1)
   -> Inside CSS:            expression(alert(1))
   -> Inside JSON:           {"key":"value</script><script>alert(1)//"}
   -> Inside template:       {{constructor.constructor('alert(1)')()}}

6. CSP BYPASS ATTEMPTS (if CSP exists):
   -> JSONP endpoints as script-src
   -> Angular/Vue template injection within allowed domains
   -> Base tag injection to redirect relative URLs
   -> Object-src if not restricted

SCORE: 0 = reflected+stored XSS found, 3 = DOM XSS only, 6 = filter bypass works, 8 = solid but CSP weak, 10 = full CSP + no XSS vectors

PHASE 3: SQL/NOSQL INJECTION TESTING

"Every query that touches user input is a confession waiting to happen."

1. SQL INJECTION (if SQL database):
   -> String-based:     ' OR '1'='1' --
   -> Numeric-based:    1 OR 1=1
   -> Union-based:      ' UNION SELECT null,username,password FROM users--
   -> Boolean blind:    ' AND 1=1-- vs ' AND 1=2--
   -> Time blind:       ' AND SLEEP(5)--
   -> Error-based:      ' AND extractvalue(1, concat(0x7e, version()))--
   -> Stacked queries:  '; DROP TABLE users;--
   -> Second-order:     Store payload, trigger on different query
   -> ORM bypass:       Raw query usage, string interpolation in queries

2. NOSQL INJECTION (MongoDB, Firestore, DynamoDB):
   -> Operator injection: {"$gt": ""} in login fields
   -> Regex injection:    {"$regex": ".*"}
   -> Where injection:    {"$where": "this.password == 'x'"}
   -> Array injection:    username[$ne]=invalid
   -> JSON injection in query parameters

3. QUERY ANALYSIS (static):
   -> Grep for raw SQL strings with concatenation/interpolation
   -> Grep for .rawQuery, .raw, db.execute with string templates
   -> Verify parameterized queries used everywhere
   -> Check ORM configurations for raw query escapes
   -> Identify any eval() or Function() with DB data

4. CONVEX-SPECIFIC (if applicable):
   -> Argument validation with v.string(), v.number() etc.
   -> Missing validators on mutation/action arguments
   -> Direct user input in query filters without validation
   -> Index usage preventing full table scans

SCORE: 0 = injectable endpoints found, 5 = parameterized but gaps, 8 = solid ORM usage, 10 = parameterized + WAF + input validation

PHASE 4: CORS MISCONFIGURATION

"A permissive CORS policy is an open invitation to steal your users' data."

1. CORS HEADER ANALYSIS
   -> Access-Control-Allow-Origin: * on authenticated endpoints? (CRITICAL)
   -> Origin reflection: does server echo back the Origin header?
   -> Null origin accepted? (file:// protocol, sandboxed iframe)
   -> Regex bypass: evil.com matching notevil.com?
   -> Subdomain wildcards: *.example.com when attacker controls sub?

2. CREDENTIAL HANDLING
   -> Access-Control-Allow-Credentials: true with wildcard origin?
   -> Cookies sent cross-origin without SameSite?
   -> Bearer tokens in requests to CORS-misconfigured endpoints?

3. PREFLIGHT ANALYSIS
   -> Access-Control-Allow-Methods: overly permissive (DELETE, PUT)?
   -> Access-Control-Allow-Headers: includes Authorization with weak origin?
   -> Access-Control-Max-Age: excessively long caching preflight?

4. CONFIGURATION AUDIT
   -> Framework CORS middleware configuration
   -> Per-route CORS overrides
   -> Proxy/CDN CORS header additions
   -> Verify CORS config matches intended trust boundaries

SCORE: 0 = wildcard with credentials, 3 = origin reflection, 5 = weak regex, 8 = proper allowlist, 10 = strict allowlist + SameSite

PHASE 5: CSP HEADERS AUDIT

"No CSP means the browser trusts everything. Everything includes the attacker's script."

1. CSP PRESENCE
   -> Content-Security-Policy header present?
   -> CSP meta tag in HTML?
   -> Report-Only mode vs enforcing mode?
   -> Different CSP for different routes?

2. DIRECTIVE ANALYSIS
   -> default-src: fallback restrictive? ('self' or 'none'?)
   -> script-src: 'unsafe-inline' present? (defeats XSS protection)
   -> script-src: 'unsafe-eval' present? (enables eval-based attacks)
   -> style-src: 'unsafe-inline' necessary or avoidable?
   -> img-src: overly permissive (data: *, blob:)?
   -> connect-src: restricts API calls to expected origins?
   -> frame-src/frame-ancestors: clickjacking protection?
   -> object-src: 'none' to prevent Flash/Java?
   -> base-uri: 'self' or 'none' to prevent base tag injection?
   -> form-action: restricts form submission targets?
   -> upgrade-insecure-requests: forces HTTPS?

3. BYPASS ANALYSIS
   -> JSONP endpoints within allowed script-src domains?
   -> CDN domains in script-src that host user content?
   -> 'strict-dynamic' properly used with nonces?
   -> Nonce generation: cryptographically random? Per-request?
   -> Hash-based CSP for inline scripts?

4. REPORTING
   -> report-uri or report-to configured?
   -> CSP violations being collected and analyzed?
   -> Report endpoint accessible and functional?

SCORE: 0 = no CSP, 3 = CSP with unsafe-inline, 5 = reasonable CSP with gaps, 8 = strong CSP, 10 = strict CSP with nonces + reporting

PHASE 6: AUTHENTICATION BYPASS TESTING

"Authentication is the front door. Most apps leave the back door wide open."

1. BYPASS TECHNIQUES
   -> Direct URL access to protected pages without auth cookie/token
   -> HTTP method switching: GET protected endpoint via POST/PUT/DELETE
   -> Parameter manipulation: remove auth params, change user_id
   -> Header manipulation: X-Forwarded-For, X-Original-URL, X-Rewrite-URL
   -> Path traversal: /admin/../admin (normalize vs raw path)
   -> Case sensitivity: /Admin vs /admin vs /ADMIN
   -> Trailing slash/dot: /admin/ vs /admin vs /admin.
   -> URL encoding: /%61dmin

2. CREDENTIAL SECURITY
   -> Password storage: bcrypt/argon2 with proper cost factor?
   -> Password reset: token entropy, expiry, single-use?
   -> Password change: requires current password?
   -> Account enumeration: login/signup/reset reveal user existence?
   -> Default credentials: admin/admin, test/test on any endpoint?

3. MULTI-FACTOR AUTHENTICATION
   -> MFA bypass: can you skip MFA step by direct URL?
   -> MFA code reuse: can the same code be used twice?
   -> MFA code brute force: rate limiting on code entry?
   -> Backup codes: secure generation and storage?

4. OAUTH/SSO ANALYSIS (if applicable)
   -> State parameter present and validated? (CSRF protection)
   -> Redirect URI validation: open redirect via OAuth?
   -> Token exchange: authorization code properly handled?
   -> Scope validation: requesting minimum necessary scopes?
   -> ID token validation: signature, issuer, audience, expiry?

5. CLERK/AUTH0/SUPABASE-SPECIFIC (if applicable)
   -> Webhook signature verification present?
   -> Client-side user object trusted without server verification?
   -> Middleware protecting all required routes?
   -> API routes checking auth independently of page auth?

SCORE: 0 = direct URL bypass works, 3 = method switching works, 5 = enumeration possible, 8 = solid with minor gaps, 10 = defense-in-depth auth

PHASE 7: SESSION MANAGEMENT

"A stolen session IS the user. No password needed."

1. SESSION TOKEN SECURITY
   -> Token entropy: cryptographically random? (>= 128 bits)
   -> Token in URL? (referer header leaks it)
   -> Token in localStorage? (XSS can steal it)
   -> HttpOnly flag on session cookies?
   -> Secure flag on session cookies? (HTTPS only)
   -> SameSite attribute? (Strict, Lax, or None?)
   -> Domain/Path scoping appropriate?

2. SESSION LIFECYCLE
   -> Session expiry configured? What duration?
   -> Idle timeout vs absolute timeout?
   -> Session invalidation on logout (server-side)?
   -> Session invalidation on password change?
   -> Concurrent session handling (limit? notify?)
   -> Session rotation after privilege escalation?

3. SESSION FIXATION
   -> New session ID generated after login?
   -> Pre-authentication session IDs rejected post-login?
   -> Session ID accepted from URL/POST params?

4. SESSION HIJACKING PROTECTION
   -> IP binding or user-agent binding?
   -> Session tokens transmitted only over HTTPS?
   -> Anti-CSRF tokens for state-changing operations?
   -> Double-submit cookie pattern or synchronizer tokens?

SCORE: 0 = session in URL/localStorage, 3 = missing HttpOnly/Secure, 5 = no expiry, 8 = solid session mgmt, 10 = all flags + rotation + CSRF

PHASE 8: JWT SECURITY ANALYSIS

"JWTs are not sessions. They're signed claims. And the signature is only as strong as the secret."

1. JWT STRUCTURE ANALYSIS
   -> Algorithm: HS256 (symmetric) vs RS256 (asymmetric)?
   -> Algorithm confusion: can you change RS256 to HS256? (CVE-2015-9235)
   -> Algorithm none: does server accept alg: "none"?
   -> Secret strength: JWT_SECRET longer than 256 bits?
   -> Secret rotation: mechanism for key rotation?

2. CLAIMS VALIDATION
   -> exp (expiry): present and enforced? How long? (target: < 15min for access)
   -> iat (issued at): present and validated?
   -> nbf (not before): used where applicable?
   -> iss (issuer): validated against expected value?
   -> aud (audience): validated against expected value?
   -> sub (subject): user ID type safe? (string vs number confusion)
   -> Custom claims: can user modify role/permissions claims?

3. TOKEN LIFECYCLE
   -> Access token lifespan: short enough? (< 15 min ideal)
   -> Refresh token: separate, longer-lived, stored securely?
   -> Refresh token rotation: new refresh token on each use?
   -> Token revocation: blacklist/whitelist mechanism?
   -> Logout: are tokens actually invalidated server-side?

4. STORAGE & TRANSMISSION
   -> Access token in httpOnly cookie vs Authorization header?
   -> Refresh token in httpOnly cookie? (never localStorage)
   -> Tokens in URL parameters? (referer leakage)
   -> Token size: not bloated with unnecessary claims?

5. COMMON ATTACKS
   -> JWT cracking: is the secret in common wordlists?
   -> JWT replay: same token valid across environments?
   -> JWT injection: manipulate claims without re-signing?
   -> Kid header injection: path traversal in key ID?
   -> JWK header injection: embed attacker's public key?

SCORE: 0 = alg none accepted, 2 = weak secret, 4 = no expiry, 6 = long-lived tokens, 8 = solid JWT, 10 = short-lived + rotation + revocation

PHASE 9: IDOR DETECTION

"User 42 shouldn't see user 43's data. But the API just needs a different number."

1. OBJECT REFERENCE ANALYSIS
   -> Sequential numeric IDs in API endpoints? (/api/users/1, /api/users/2)
   -> UUID vs sequential ID for user-facing resources?
   -> Guessable patterns in resource identifiers?

2. HORIZONTAL PRIVILEGE TESTING
   FOR EVERY data-access endpoint:
   -> Authenticate as User A
   -> Request User B's resources by changing ID parameter
   -> Check: /api/orders/{orderId} — can User A see User B's order?
   -> Check: /api/profile/{userId} — can User A edit User B's profile?
   -> Check: /api/files/{fileId} — can User A download User B's file?
   -> Check: /api/messages/{threadId} — can User A read User B's DMs?

3. VERTICAL PRIVILEGE TESTING
   -> Regular user accessing admin endpoints by ID manipulation
   -> Changing role parameter in profile update
   -> Accessing management functions by guessing endpoint IDs
   -> GraphQL node lookup bypassing authorization

4. INDIRECT REFERENCES
   -> File path manipulation: /api/files?path=../../etc/passwd
   -> Database reference manipulation: changing foreign keys
   -> Batch operations: /api/bulk?ids=[1,2,3,4,5] — which belong to you?
   -> GraphQL nested queries: accessing related objects you shouldn't see

5. CONVEX-SPECIFIC (if applicable)
   -> Document ID predictability
   -> Query filters checking ownership (ctx.auth)
   -> Mutations validating document ownership before update
   -> Missing authorization in internal functions called from actions

SCORE: 0 = horizontal IDOR on user data, 3 = IDOR on non-critical data, 5 = vertical IDOR, 8 = mostly protected, 10 = all endpoints authorization-checked

PHASE 10: SSRF PROBING

"When the server makes requests on behalf of the user, the user becomes the server."

1. SSRF VECTOR IDENTIFICATION
   -> URL parameters that trigger server-side fetches
   -> Image/file URL imports (avatar, OG image, webhook URL)
   -> PDF generators, screenshot services, link previewers
   -> Webhook delivery endpoints
   -> OAuth callback URLs
   -> Import/export functionality with URLs

2. INTERNAL NETWORK PROBING
   -> Can you reach localhost (127.0.0.1, 0.0.0.0)?
   -> Can you reach cloud metadata? (169.254.169.254, metadata.google.internal)
   -> Can you reach internal services? (redis://localhost, http://internal-api)
   -> DNS rebinding: external domain resolving to internal IP?

3. BYPASS TECHNIQUES
   -> IP address formats: decimal, octal, hex (0x7f000001)
   -> IPv6: [::1], [::ffff:127.0.0.1]
   -> URL parsing confusion: http://evil.com@127.0.0.1
   -> Redirect chains: external URL -> 302 -> internal
   -> DNS rebinding: first resolve to external, second to internal
   -> Protocol smuggling: gopher://, file://, dict://

4. CLOUD METADATA EXPLOITATION
   -> AWS: http://169.254.169.254/latest/meta-data/iam/security-credentials/
   -> GCP: http://metadata.google.internal/computeMetadata/v1/
   -> Azure: http://169.254.169.254/metadata/instance
   -> IMDSv2 enforcement check (AWS)

SCORE: 0 = metadata accessible, 3 = internal network reachable, 5 = partial SSRF, 8 = URL validated but bypassable, 10 = allowlist + no user-controlled URLs

PHASE 11: OPEN REDIRECT TESTING

"A trusted domain redirecting to an attacker's site is phishing on a silver platter."

1. REDIRECT PARAMETER DISCOVERY
   -> Scan for: redirect, return, returnUrl, next, url, continue, dest, redir, goto
   -> Login redirects: /login?next=/dashboard -> /login?next=http://evil.com
   -> Logout redirects: /logout?redirect=http://evil.com
   -> OAuth redirects: /auth/callback?redirect_uri=http://evil.com

2. BYPASS TECHNIQUES
   -> Protocol-relative: //evil.com
   -> Backslash: /\evil.com (server normalizes differently than browser)
   -> At sign: http://legit.com@evil.com
   -> Double encoding: %252F%252Fevil.com
   -> Null byte: http://legit.com%00.evil.com
   -> Tab/newline: http://legit.com%09.evil.com
   -> Data URI: data:text/html,<script>alert(1)</script>
   -> JavaScript URI: javascript:alert(1)
   -> Fragment: http://legit.com#@evil.com
   -> Path: /redirect/http://evil.com
   -> Subdomain: http://evil.legit.com (if DNS controlled)

3. IMPACT ASSESSMENT
   -> Can redirect steal OAuth tokens/codes?
   -> Can redirect be chained with XSS?
   -> Does redirect preserve authentication state?
   -> Can redirect serve malicious downloads?

SCORE: 0 = open redirect on auth pages, 3 = open redirect on non-auth, 5 = bypassable validation, 8 = strict validation, 10 = allowlist only + no user-controlled redirects

PHASE 12: FILE UPLOAD VULNERABILITIES

"Every file upload is a potential web shell if you trust the Content-Type."

1. FILE TYPE VALIDATION
   -> Extension check: server-side or client-side only?
   -> Extension bypass: .php.jpg, .pHp, .php%00.jpg, .php;.jpg
   -> MIME type check: Content-Type header vs magic bytes?
   -> Magic bytes validation: does server check file content?
   -> Double extension: file.php.jpg served as PHP?

2. FILE STORAGE SECURITY
   -> Uploaded files in web-accessible directory?
   -> Uploaded files served with original filename?
   -> Uploaded files served with original Content-Type?
   -> Path traversal in filename: ../../etc/cron.d/backdoor
   -> Overwrite protection: can upload overwrite existing files?

3. FILE CONTENT ATTACKS
   -> SVG with embedded JavaScript (XSS via SVG)
   -> HTML file upload (stored XSS)
   -> XML file with XXE payload
   -> ZIP bomb / decompression bomb
   -> Polyglot files (GIFAR: GIF + JAR)
   -> ImageTragick: malicious image exploiting ImageMagick

4. SIZE AND RATE LIMITS
   -> Maximum file size enforced server-side?
   -> Maximum number of concurrent uploads?
   -> Storage quota per user?
   -> Virus/malware scanning on uploads?

SCORE: 0 = web shell uploadable, 3 = XSS via SVG, 5 = path traversal, 8 = solid validation, 10 = content validation + isolated storage + scanning

PHASE 13: RATE LIMITING VERIFICATION

"Without rate limiting, every endpoint is a DoS waiting to happen."

1. CRITICAL ENDPOINTS
   -> Login: rate limited? After how many attempts?
   -> Registration: rate limited? (mass account creation)
   -> Password reset: rate limited? (email bombing)
   -> API endpoints: per-user and per-IP limits?
   -> Payment operations: rate limited? (double-charge prevention)
   -> Search/query: rate limited? (resource exhaustion)

2. RATE LIMIT IMPLEMENTATION
   -> Where enforced: application, reverse proxy, WAF, CDN?
   -> Limit granularity: per IP? Per user? Per endpoint?
   -> Reset mechanism: sliding window? Fixed window? Token bucket?
   -> Response on limit: 429 with Retry-After header?

3. BYPASS TECHNIQUES
   -> IP rotation via X-Forwarded-For header manipulation
   -> Distributed requests from multiple IPs
   -> API key rotation (if key-based limiting)
   -> Different endpoints same function (/api/v1/login vs /api/v2/login)
   -> Case variation in endpoint paths
   -> HTTP method variation (GET vs POST same endpoint)

4. RESOURCE EXHAUSTION
   -> Regex DoS (ReDoS): catastrophic backtracking in input validation?
   -> GraphQL complexity: deeply nested queries without depth limit?
   -> Pagination: requesting page_size=999999?
   -> Batch operations without batch size limit?
   -> WebSocket message flooding protection?

SCORE: 0 = no rate limiting on login, 3 = login limited but API not, 5 = basic limits but bypassable, 8 = comprehensive limits, 10 = WAF + app-level + monitoring

PHASE 14: BRUTE FORCE PROTECTION

"Given enough attempts, every password is discoverable. The question is how many attempts you allow."

1. LOGIN PROTECTION
   -> Account lockout after N failures? (what N?)
   -> Lockout duration: temporary or permanent until reset?
   -> Lockout scope: per IP, per account, or both?
   -> CAPTCHA after N failures?
   -> Progressive delays (exponential backoff)?
   -> Notification to user on failed login attempts?

2. TOKEN/CODE BRUTE FORCE
   -> Password reset token: length, charset, entropy?
   -> MFA code: rate limited? Lockout after failures?
   -> API key: length and complexity?
   -> Invitation codes: guessable patterns?
   -> Short codes (6-digit): protected against enumeration?

3. ENUMERATION PROTECTION
   -> Username enumeration via login error messages?
   -> Email enumeration via registration ("email already taken")?
   -> Phone enumeration via SMS verification?
   -> Timing attacks: different response times for valid vs invalid users?

4. CREDENTIAL STUFFING DEFENSE
   -> Compromised password database check (HIBP API)?
   -> Device fingerprinting for anomalous logins?
   -> Geolocation-based alerts for new locations?
   -> Common password list blocking?

SCORE: 0 = no lockout/no CAPTCHA, 3 = lockout but enumerable, 5 = basic protection, 8 = comprehensive, 10 = lockout + CAPTCHA + anomaly detection + HIBP

PHASE 15: SECRETS SCANNING

"The most common vulnerability isn't code — it's the API key committed three months ago."

1. ENVIRONMENT VARIABLES
   -> .env file in repository? .env.local? .env.production?
   -> .env in .gitignore? (verify it's actually ignored)
   -> Secrets in docker-compose.yml or Dockerfile?
   -> Secrets in CI/CD configuration (GitHub Actions, Vercel)?
   -> Environment variables logged or exposed in error messages?

2. GIT HISTORY ANALYSIS
   -> Run: git log --all --diff-filter=D -- '*.env*'
   -> Run: git log -p --all -S 'API_KEY\|SECRET\|TOKEN\|PASSWORD' -- '*.ts' '*.js' '*.py'
   -> Check: removed .env files still in git history
   -> Check: secrets rotated after accidental commit?
   -> Check: force push used to "hide" secrets (still in reflog)?

3. CLIENT-SIDE BUNDLES
   -> Grep built JS for: API_KEY, SECRET, TOKEN, PRIVATE, sk_, pk_
   -> Check NEXT_PUBLIC_ variables: only non-sensitive values?
   -> Source maps exposing server-side code in production?
   -> Hardcoded API keys in client-side JavaScript?
   -> Stripe publishable vs secret key confusion?

4. CONFIGURATION FILES
   -> Firebase config exposed (apiKey, authDomain, etc.)?
   -> AWS credentials in config files?
   -> Database connection strings with credentials?
   -> Third-party service keys (Twilio, SendGrid, etc.)?

5. HIGH-ENTROPY STRING DETECTION
   -> Scan for base64-encoded strings > 20 chars in source
   -> Scan for hex strings > 32 chars in source
   -> Scan for strings matching API key patterns:
      sk_live_, sk_test_, AKIA, AIza, ghp_, gho_,
      xoxb-, xoxp-, Bearer, Basic, AWS_ACCESS_KEY
   -> Use: trufflehog, gitleaks, or manual grep patterns

SCORE: 0 = active secrets in repo/bundles, 3 = rotated but still in history, 5 = .env committed but removed, 8 = clean repo, 10 = clean repo + secret manager + rotation

PHASE 16: DEPENDENCY CVE AUDIT

"Your code is secure. Your dependencies are not. They're 90% of your attack surface."

1. VULNERABILITY SCANNING
   -> Run: npm audit / yarn audit / pnpm audit
   -> Run: pip-audit / safety check (Python)
   -> Check: GitHub Dependabot alerts
   -> Analyze: critical, high, medium, low counts
   -> CRITICAL/HIGH: immediate remediation required

2. DEPENDENCY ANALYSIS
   -> Total dependency count (direct + transitive)
   -> Outdated dependencies: how many major versions behind?
   -> Unmaintained packages: last publish > 2 years ago?
   -> Deprecated packages still in use?
   -> Packages with known supply chain attacks?

3. LOCK FILE INTEGRITY
   -> Lock file (package-lock.json, yarn.lock) present and committed?
   -> Integrity hashes present in lock file?
   -> No manual edits to lock file?
   -> Lock file matches package.json?

4. SUPPLY CHAIN SECURITY
   -> Typosquatting risk: similar-named packages?
   -> Maintainer account compromises: recent ownership transfers?
   -> Install scripts: postinstall running arbitrary code?
   -> Package provenance: npm provenance or Sigstore signatures?
   -> Pin dependencies to exact versions in production?

5. SUBRESOURCE INTEGRITY
   -> CDN-loaded scripts have integrity attributes?
   -> SRI hashes match expected content?
   -> Fallback mechanism if CDN compromised?

SCORE: 0 = critical CVEs unfixed, 3 = high CVEs present, 5 = medium CVEs + outdated, 8 = all patched, 10 = all patched + SRI + provenance + minimal deps

PHASE 17: SSL/TLS CONFIGURATION

*"HTTP

…(truncated)