When to use this
- New login flow, permission check, API key scheme, or session handling code.
- Adding a new endpoint that returns or mutates another user's data by ID.
- Not for reviewing a well-established, unchanged auth library -- scope to what's new or modified.
The skill file
Copy this verbatim. It's written in the SKILL.md format (YAML frontmatter + markdown instructions) that Claude Code, and increasingly other agent tools, read directly.
--- name: auth-flow-reviewer description: Review a new or changed authentication/authorization flow for missing object-level authorization checks, token/session handling mistakes, and privilege-escalation paths. Use when a diff touches login, permissions, API keys, or session logic. --- # Auth Flow Reviewer Most real-world auth bugs are not cryptography mistakes -- they're missing authorization checks. Prioritize accordingly. ## Checklist 1. **Authentication vs. authorization**: does every new endpoint that should require login actually check for a valid session/token, AND separately check the caller is *allowed* to act on the specific resource requested (not just any resource)? A user being logged in doesn't mean they're allowed to fetch order #4471. 2. **Object-level checks**: for any endpoint taking a resource ID from the request (URL param, body), confirm the code verifies the current user owns/can-access that specific ID -- not just that the ID exists. 3. **Token handling**: are tokens transmitted only over TLS, not logged, not embedded in URLs (which land in logs/browser history), and does the code check expiry and signature, not just presence? 4. **Session fixation / privilege escalation**: does login rotate the session identifier? Does a role/permission change take effect immediately or only on next login (and is that intentional)? 5. **Default-deny**: does a new permission check fail closed (deny on error/unknown state) or fail open? ## Output For each finding: which checklist item, the exact code path, the concrete scenario (which user could access which other user's data, and how), and the fix -- almost always "add the missing object-level check using the existing auth middleware/pattern," not a new auth scheme.
Installing it elsewhere
The frontmatter/body split above is Claude Code's convention. Here's how to carry the same instructions into other tools:
Save the file below verbatim (frontmatter included) at that path, project-local or in ~/.claude/skills/ for a user-level skill. Claude Code loads the name/description pair to decide when to pull it in, or you invoke it directly as /auth-flow-reviewer.
Convert the YAML frontmatter to Cursor's rule format (description, globs, alwaysApply: false) and keep the markdown body as the rule content. Cursor surfaces it by description match, same idea as Claude Code's auto-load.
Codex CLI (and increasingly other agentic CLIs) read AGENTS.md at the repo root as always-on instructions. Paste the markdown body under a heading like ## {title}; for GitHub Copilot's coding agent, the equivalent file is .github/copilot-instructions.md.
Append the markdown body to .windsurfrules at the repo root. Windsurf treats the whole file as always-on context, so keep only the instructions you want applied on every request.
- Confirming authentication exists and stopping there without checking object-level authorization -- this is the single most common real-world auth bug (IDOR).
- Recommending a custom token scheme when the codebase has an established, already-audited one.
- Treating a fail-open error handler in a permission check as low severity -- it usually isn't.