auth-review
Skill18 starsChanged 7 months agoMITView on GitHub
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.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- ashrafiucse/security-audit-skillstheir own version, first seen Oct 13, 2026
- Jinbae10/skillstheir own version, first seen Jul 7, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- ashrafiucse/security-audit-skills★ 2same name
- Jinbae10/skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository10 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- auth0-to-descopeSkill
- descope-authSkill
- descope-byos-builderSkill
- descope-fga-schemaSkill
- descope-terraformSkill
- okta-cis-to-descopeSkill
- pingone-to-descopeSkill
- stytch-to-descopeSkill
- workos-to-descopeSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. About 0 are common, 11 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Run these phases in order.
- Distinctive: line 38
Before calling a check missing, confirm no upstream middleware, decorator, guard, filter, interceptor, framework default, or reverse proxy …
- Very specific: line 42
Create ./auth-review/ if absent.
- Distinctive: line 53
After writing, summarize severity counts to the user and point at the file path.
- Very specific: line 63
Always include a CWE ID (e.g., CWE-287, CWE-639, CWE-862, CWE-863).
- Distinctive: line 67
DO NOT modify source code.
- Distinctive: line 68
DO NOT execute the application, run network probes, or make outbound requests.
- Very specific: line 69
DO NOT report a finding without a file.ext:line reference and evidence snippet.
- Distinctive: line 70
DO NOT flag a missing check before confirming no upstream middleware, guard, decorator, or proxy enforces it.
- Distinctive: line 71
DO NOT invent CWE IDs, CVSS scores, or framework behaviors — if unsure, mark the finding "unconfirmed" and move it to Open Questions.
- Very specific: line 72
DO NOT include secrets, tokens, private keys, or real user data in the report.
- Distinctive: line 73
DO NOT commit the report to git unless the user asks.
- Distinctive: line 74
DO NOT create GitHub issues or PRs directly.
- Distinctive: line 75
DO NOT stop after finding one bug.
- Distinctive: line 76
DO NOT trust code comments or documentation over the code itself.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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:linereference 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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.