descope/auth-review
skills/auth-review/SKILL.md
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.
$ install --global
skillsauthnpx skillsauth add descope/skills auth-reviewInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 13, 2026, 3:17 AM266.8s5 files scanned
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:
- 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.
Related Skills
descope/descope-byos-builder
development
VerifiedTrustedCommunity
Use when building React "Bring Your Own Screen" (BYOS) custom UI on top of a Descope flow — takes exported flow JSONs, extracts the real interaction IDs and outputs, generates BYOS components that match hosted parity, and avoids the rediscovery-the-hard-way failure modes (silent form rejection, shared screen-name collisions, anonymous-session stickiness, nested-form hydration errors, wrong form keys, dead-end buttons, missing OAuth provider field).
7SKILL.mdUpdated May 30, 2026
descope/okta-cis-to-descope
development
VerifiedTrustedCommunity
Use this skill whenever anyone asks about migrating from Okta Customer Identity Service (CIS) to Descope — whether they're a developer doing it themselves or a technical lead evaluating the move. Triggers on: "how do I migrate from Okta", "replace Okta CIS with Descope", "we're moving off Okta", "Okta to Descope", "switch from Okta", "our app uses okta-auth-js / @okta/okta-react / @okta/okta-angular / @okta/oidc-middleware / okta-jwt-verifier and we want to use Descope instead", or any question about Okta CIS features (Sign-On Policies, Authorization Servers, Authenticators, Identity Providers, Log Streams, Service Apps, scp claim) in the context of Descope. Works for any language or framework with a Descope SDK. Always use this skill before producing migration guidance — do not rely on memory alone.
7SKILL.mdUpdated May 28, 2026
descope/descope-terraform
development
VerifiedTrustedCommunity
Set up and manage Descope projects with Terraform. Use when configuring authentication infrastructure as code, managing environments, creating roles/permissions, setting up connectors, or deploying Descope project configurations.
6SKILL.mdUpdated May 13, 2026
descope/descope-fga-schema
testing
VerifiedTrustedCommunity
Author, edit, or apply a Descope FGA schema using the ReBAC/ABAC DSL. Use this skill whenever the user asks to create a new FGA schema, modify an existing one, add types/relations/permissions/conditions, review an authorization model, or apply schema changes to a Descope project. Trigger even if the user says things like "set up authorization", "define roles and permissions", "add team-based access", "make this endpoint check FGA", or "update my authz model" — these almost always mean an FGA schema change.
6SKILL.mdUpdated May 13, 2026