Engineering Auth Authorization

Authorization Review Prompt

Hunt the broken-access-control bug — review code for missing per-resource checks, IDOR, and 'logged in' mistaken for 'allowed', the vulnerability class that tops the OWASP list.

Overview

Broken access control is the most common serious web vulnerability, and a generic review skims past it because the code looks fine — it authenticates, it just doesn't authorize. This prompt reviews specifically for authorization: is every object access checked against the caller's permissions, not just their login? Can a user reach another user's record by changing an ID? It finds the per-resource check that isn't there.

How to use this resource

  1. Gather the code and its access rules

    Collect the endpoints or handlers that touch protected resources and note who is supposed to be allowed to do what. The review checks authorization, not just login.

  2. Open this resource in Code Review Prompt Generator

    Load the prompt into Code Review Prompt Generator and paste in the code. It reviews specifically for missing per-resource checks and IDOR rather than skimming past them.

  3. Review the access-control findings

    Read each finding - an object access not checked against the caller, an ID a user could change to reach another record - ranked by risk.

  4. Close the gaps and re-review

    Add the missing per-resource checks the review flags, then re-run it to confirm no broken-access path remains.

Why This Works

  • Broken access control is OWASP #1; a dedicated lens catches what generic review misses
  • IDOR hides in code that authenticates correctly but never authorizes
  • Checking API-level (not UI) enforcement catches the most common real bypass

Best for

  • Apps with multi-user data and per-record access
  • Code that handles other users' or tenants' data
  • Pre-release review of authorization-sensitive paths

Not for

  • Designing the access model — use the RBAC Design Prompt
  • Broad security review — use the Security Code Review Prompt

Use cases

  • Reviewing endpoints for missing object-level authorization
  • Hunting IDOR before a release
  • Checking that API authorization isn't enforced only in the UI

FAQ

How is the Authorization Review Prompt different from a general security code review?

Its ROLE line scopes the review to broken access control only — not general security, just authorization — so it hunts the six flaws under REVIEW FOR AUTHORIZATION FLAWS (per-resource checks, IDOR, authenticated vs authorized, missing checks, client-side trust, scope leaks) rather than skimming XSS, injection, and secrets. For broad coverage, notFor points to the Security Code Review Prompt.

Why does the authorization review mark some findings CRITICAL and others just MAJOR or MINOR?

The SEVERITY section tells the model to tag every finding [CRITICAL]/[MAJOR]/[MINOR], and it hard-codes one rule: missing object-level authorization and IDOR are CRITICAL. The OUTPUT then groups findings by severity, each citing the exact location and the access it wrongly allows — and stops there, since it says Findings only, do not rewrite the code.

Can I rely on the authorization review prompt instead of a professional security audit?

Treat it as a focused review pass, not an audit substitute. code-review-prompt-generator outputs a prompt you run in your own assistant; the findings are that model's read of the six checks against your pasted routes, controllers, data-access, and auth middleware — recommendations to verify, not a guarantee it caught every broken-access path. You own confirming fixes and shipping.

More resources from Code Review Prompt Generator

Resources that pair well

Related tools

Workflows that use this resource

Guides for this resource

Tip: Save time by exploring related resources and tools that integrate with this resource.