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:
- Executive summary with counts by severity.
- Endpoint inventory (Phase 1).
- Authorization matrix (Phase 2).
- Findings — each with title, severity, CWE,
file:line, evidence, exploit reasoning, remediation.
- "Issues to file" — findings pre-formatted as ready-to-paste issue bodies.
- 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.
1---2name: auth-review3description: 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.4---56# Auth Review78Perform 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.910## When to Use1112- User invokes `/auth-review`.13- Requests like "audit auth", "find authz bugs", "review access control", "check for IDOR", "identity security review".14- Pre-release hardening or post-incident forensic code review focused on identity.1516## Workflow1718Run these phases **in order**. Do not skip ahead.1920### Phase 1 — Enumerate every entrypoint2122Identify 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.2324**Deliverable:** an **Endpoint Inventory** table: `method`, `path / trigger`, `handler (file:line)`, `auth required? (y/n/unknown)`, `roles or scopes`, `notes`.2526Reconcile against router files, OpenAPI specs, and GraphQL schemas before moving on.2728### Phase 2 — Build the authorization matrix2930For 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.3132**Deliverable:** an **Authorization Matrix** table: `endpoint`, `expected principal`, `enforced check (file:line)`, `gap`.3334### Phase 3 — Apply the vulnerability catalog3536Walk `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.3738Before 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.3940### Phase 4 — Write the report4142Create `./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`.4344The report must include:45461. Executive summary with counts by severity.472. Endpoint inventory (Phase 1).483. Authorization matrix (Phase 2).494. Findings — each with title, severity, CWE, `file:line`, evidence, exploit reasoning, remediation.505. "Issues to file" — findings pre-formatted as ready-to-paste issue bodies.516. Open questions the maintainer must answer.5253After writing, summarize severity counts to the user and point at the file path. Do not create issues or PRs.5455## Severity Scale5657| Level | Meaning |58|--------|---------|59| High | Exploitable by unauthenticated or low-privilege attacker; leads to account takeover, data breach, privilege escalation, or tenant crossing. |60| Medium | Requires specific conditions, partial impact, or defense-in-depth failure. |61| Low | Hardening recommendation; minor information disclosure; missing best practice. |6263Always 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.6465## DO NOT6667- DO NOT modify source code. This skill is read-only.68- DO NOT execute the application, run network probes, or make outbound requests.69- DO NOT report a finding without a `file.ext:line` reference and evidence snippet.70- DO NOT flag a missing check before confirming no upstream middleware, guard, decorator, or proxy enforces it.71- DO NOT invent CWE IDs, CVSS scores, or framework behaviors — if unsure, mark the finding "unconfirmed" and move it to Open Questions.72- DO NOT include secrets, tokens, private keys, or real user data in the report. Redact as `[REDACTED]`.73- DO NOT commit the report to git unless the user asks.74- DO NOT create GitHub issues or PRs directly. Output issue-ready text and let the user file them.75- DO NOT stop after finding one bug. Enumerate everything, then report.76- DO NOT trust code comments or documentation over the code itself. A comment saying "admin only" is not a security control.7778## References7980- `references/enumeration.md` — entrypoint patterns across HTTP, GraphQL, WebSocket, RPC, serverless, and background stacks.81- `references/vulnerability-catalog.md` — full taxonomy with detection heuristics, CWE IDs, and fixes.82- `references/authz-matrix.md` — matrix schema and expected-principal inference rules.83- `references/report-template.md` — exact report structure and issue-body format.
descope