What Is Broken Access Control in AI-Built Apps?

Broken access control is the failure to enforce authorization boundaries after identity is established. It's OWASP's #1 web application risk category, and in AI-built apps it usually appears as role checks without resource ownership or policy consistency.

The common failure pattern is "authenticated but over-authorized." A user with a valid session can still read, update, or delete resources that belong to a different tenant when routes and policies do not validate actor-to-resource relationships.

A plain-English analogy: checking that someone has a hotel keycard is not enough. You must also verify that the card opens the specific room they booked, not every room on the floor.

Start free scan | See sample audit

The Four Ways Access Control Breaks in AI-Built Apps

Broken access control isn't one bug — it's an umbrella category that shows up in a handful of predictable, recurring shapes:

1. BOLA/IDOR — an endpoint returns another user's or tenant's record when given a substituted ID. The single most common launch blocker in AI-generated APIs.
2. Role-only authorization — code checks role === "admin" but never checks whether the actor owns the specific object being touched. See RBAC vs ABAC vs FGAC for the authorization models that actually close this gap.
3. Server-side mutation gaps — a write path that runs on the server but still trusts a client-supplied ID without binding it to the authenticated actor's scope. Covered in depth in Next.js Server Action security.
4. Function-level escalation — a UI hides an admin action from regular users, but the underlying route or server action has no server-side check at all, so anyone who calls it directly gets through.

Agentic Risk (Cursor, v0, Bolt)

Ubserve Internal Audit data (2026) found 34.2% of AI-assisted codebases had at least one privileged path callable by non-privileged users due to generated "helper" routes and partial role gates.

How to Audit for It

• Enumerate every route and server action that reads or writes tenant- or user-scoped data.
• For each one, ask two separate questions: "does this require login?" and "does this verify the logged-in actor owns the specific resource?" AI tools reliably answer the first and skip the second.
• Test with a second account: authenticate as User B, then request User A's resource IDs. Anything that returns data is a confirmed broken-access-control finding, not a theoretical one.

Wrong vs. Right

// WRONG: role check only
if (session.user.role === "member") allow();

// RIGHT: role + object + tenant + action scope
authorize({
  actorId: session.user.id,
  tenantId: session.tenantId,
  action: "invoice:update",
  resourceTenantId: invoice.tenantId,
});

Copy-Paste Fix Prompt for Cursor/Claude

Harden access control in my app.
1. Build a matrix of actions vs roles vs resources.
2. Locate routes/actions where role checks exist without ownership checks.
3. Add policy middleware/helpers enforcing actor-resource-tenant consistency.
4. Add tests for horizontal and vertical privilege escalation.
Return patches + authorization matrix.

Run a free URL scan. If it finds issues, paid plans unlock the full report, exact AI fix prompts, PDF export, and deeper audit coverage.