mcpField
A
auth-review

auth-review

github.com/descopeSecurity1882 installsUpdated 1d ago
Repository

About auth-review

Auth Review is a read-only, framework-agnostic skill for auditing authentication and authorization in a codebase. It produces an issue-ready triage report with endpoint inventory, authorization matrix, and evidence-backed findings.

Key features

  1. 01Enumerate external and semi-trusted entrypoints
  2. 02Build an endpoint authorization matrix
  3. 03Check code against vulnerability categories
  4. 04Write dated reports with issue-ready findings
  5. 05Keep review static and read-only

Use cases

  1. 01Review access controls before a release
  2. 02Investigate authentication after an incident
  3. 03Check a codebase for IDOR and authorization gaps

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/descope/skills --skill auth-review

After installing, type/auth-reviewin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
authz-matrix.md
enumeration.md
report-template.md
vulnerability-catalog.md

Details

From the project README

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

LevelMeaning
HighExploitable by unauthenticated or low-privilege attacker; leads to account takeover, data breach, privilege escalation, or tenant crossing.
MediumRequires specific conditions, partial impact, or defense-in-depth failure.
LowHardening 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.

Comments

Markdown supported