SKILL.md

---
name: auth-review
description: Static security review for authentication and authorization vulnerabilities. Use when the user invokes /auth-review, asks to audit auth, find identity breaches, review access control, hunt for IDOR/BOLA, or check authorization. Framework- and vendor-agnostic. Enumerates every route/endpoint, builds an authorization matrix, applies a vulnerability catalog, and writes a triage report ready to turn into issues or PRs.
---

# Auth Review

Perform a **static, read-only** security review of authentication and authorization in the current codebase. Framework- and vendor-agnostic. Output: a triage report in `./auth-review/` with findings ready to file as issues or PRs.

## When to Use

- User invokes `/auth-review`.
- Requests like "audit auth", "find authz bugs", "review access control", "check for IDOR", "identity security review".
- Pre-release hardening or post-incident forensic code review focused on identity.

## Workflow

Run these phases **in order**. Do not skip ahead.

### Phase 1 — Enumerate every entrypoint

Identify every code path reachable by an external or semi-trusted caller. See `references/enumeration.md` for exhaustive patterns. A single repo often mixes HTTP, GraphQL, WebSocket, queue consumers, serverless handlers, and admin CLIs — list them all.

**Deliverable:** an **Endpoint Inventory** table: `method`, `path / trigger`, `handler (file:line)`, `auth required? (y/n/unknown)`, `roles or scopes`, `notes`.

Reconcile against router files, OpenAPI specs, and GraphQL schemas before moving on.

### Phase 2 — Build the authorization matrix

For each endpoint answer: *who should reach this, and what does the code actually enforce?* Use `references/authz-matrix.md` to infer the expected principal from conventions and classify gaps.

**Deliverable:** an **Authorization Matrix** table: `endpoint`, `expected principal`, `enforced check (file:line)`, `gap`.

### Phase 3 — Apply the vulnerability catalog

Walk `references/vulnerability-catalog.md` category by category. For each, run the detection heuristics, then **read** the matched files to confirm. Never flag from a grep hit alone.

Before calling a check missing, confirm no upstream middleware, decorator, guard, filter, interceptor, framework default, or reverse proxy enforces it. Trace at least one concrete caller path end-to-end for each finding. If a check is conditional, record the condition and whether an attacker controls it.

### Phase 4 — Write the report

Create `./auth-review/` if absent. Write to `./auth-review/report-YYYY-MM-DD.md` (append `-HHMM` if one already exists for today). Use the structure in `references/report-template.md`.

The report must include:

1. Executive summary with counts by severity.
2. Endpoint inventory (Phase 1).
3. Authorization matrix (Phase 2).
4. Findings — each with title, severity, CWE, `file:line`, evidence, exploit reasoning, remediation.
5. "Issues to file" — findings pre-formatted as ready-to-paste issue bodies.
6. Open questions the maintainer must answer.

After writing, summarize severity counts to the user and point at the file path. Do not create issues or PRs.

## Severity Scale

| Level  | Meaning |
|--------|---------|
| High   | Exploitable by unauthenticated or low-privilege attacker; leads to account takeover, data breach, privilege escalation, or tenant crossing. |
| Medium | Requires specific conditions, partial impact, or defense-in-depth failure. |
| Low    | Hardening recommendation; minor information disclosure; missing best practice. |

Always include a CWE ID (e.g., CWE-287, CWE-639, CWE-862, CWE-863). Use identifiers from `references/vulnerability-catalog.md` — do not invent IDs.

## DO NOT

- DO NOT modify source code. This skill is read-only.
- DO NOT execute the application, run network probes, or make outbound requests.
- DO NOT report a finding without a `file.ext:line` reference and evidence snippet.
- DO NOT flag a missing check before confirming no upstream middleware, guard, decorator, or proxy enforces it.
- DO NOT invent CWE IDs, CVSS scores, or framework behaviors — if unsure, mark the finding "unconfirmed" and move it to Open Questions.
- DO NOT include secrets, tokens, private keys, or real user data in the report. Redact as `[REDACTED]`.
- DO NOT commit the report to git unless the user asks.
- DO NOT create GitHub issues or PRs directly. Output issue-ready text and let the user file them.
- DO NOT stop after finding one bug. Enumerate everything, then report.
- DO NOT trust code comments or documentation over the code itself. A comment saying "admin only" is not a security control.

## References

- `references/enumeration.md` — entrypoint patterns across HTTP, GraphQL, WebSocket, RPC, serverless, and background stacks.
- `references/vulnerability-catalog.md` — full taxonomy with detection heuristics, CWE IDs, and fixes.
- `references/authz-matrix.md` — matrix schema and expected-principal inference rules.
- `references/report-template.md` — exact report structure and issue-body format.