BROKEN OBJECT-LEVEL AUTH IN AI-GENERATED CRUD

We tested every AI-built app in our corpus that exposes a CRUD-style API for the OWASP API #1 risk: BOLA. Of 1,514 apps, 487 (32%) had at least one route that returned another user’s data when an ID was substituted. The breakdown below is by platform, by HTTP method, by resource type — the first quantitative cut of how AI-generated CRUD actually fails.

Headline numbers

By HTTP method

We tested every observed verb separately. A route can be vulnerable on read but safe on write, or vice versa.

PUT is the worst because it replaces the entire row — once an attacker can write to another user’s resource, every other field on that row is also overwritable. PATCH has similar exposure on the fields included in the request. POST is the safest verb because you cannot meaningfully BOLA a create operation.

By resource type

Routes were classified by the resource name in the path. Naming gravity matters here too — AI generators converge on the same resource names, which makes them both more numerous and more attackable.

invoices and messages are the worst because they are typically the most “owned” resources — a clear single owner with no expected sharing — and AI generators do not consistently enforce that ownership.

Per-platform breakdown

Lovable’s PATCH skew comes from how the generator handles “edit profile” patterns — it produces a single PATCH endpoint that accepts arbitrary fields, including the user_id that should never be edited. This is the same root cause as the self-editable role finding from the main benchmark.

CWE / OWASP mapping

Every BOLA finding in this study is classified against the same canonical taxonomy. The columns map one-to-many — a single finding usually carries the OWASP API entry plus one or two CWE codes.

The CWE-639 / CWE-863 split matters during triage. A route that has no ownership check is CWE-639 — the user-controlled ID flows straight to a query. A route that has a partial check (filtering by tenant but not by user, for example) is CWE-863 — the authorization logic exists but is incorrect. The fixes are different: the first needs an added clause; the second needs the existing logic widened.

Where the bug hides — five distinct shapes

We see five distinct surfaces in production. Each one is “missing ownership check” but the place the check is missing differs, and the detection probe is different per surface.

Shapes 3 and 4 are the under-counted ones — static scanners do not flag them and runtime scanners need bespoke probes. The cross-tenant aggregate failure is invisible on a single-user test; you have to compare two tenants’ dashboards to notice the leak.

Pattern: the missing line

The fix for almost every BOLA finding is a single line. The vulnerable code looks like this:

// vulnerable — Lovable / Bolt / Cursor all generate variants of this
app.get('/api/invoices/:id', requireAuth, async (req, res) => {
  const invoice = await db.invoice.findById(req.params.id);
  res.json(invoice);
});

The fix is one check:

app.get('/api/invoices/:id', requireAuth, async (req, res) => {
  const invoice = await db.invoice.findById(req.params.id);
  if (invoice.user_id !== req.user.id) return res.status(404).end();
  res.json(invoice);
});

Why is this not generated? Because the AI’s training data is full of the first pattern — most public CRUD tutorials skip the ownership check for brevity. The model learned the wrong default.

Wrong fixes that look right

These are the patterns we see when teams notice the bug but apply the wrong remediation. Each one ships and feels like a fix; none of them close the gap.

// WRONG: checks the requester is logged in, not that they own the resource
const invoice = await db.invoice.findById(req.params.id);
if (req.user) return res.json(invoice);

// WRONG: checks tenant scope but not user scope inside the tenant
const invoice = await db.invoice.findById(req.params.id);
if (invoice.tenant_id === req.user.tenant_id) return res.json(invoice);
// A user in tenant A can still read other users' invoices within tenant A.

// WRONG: checks ownership against a header the client controls
const userId = req.headers['x-user-id'];
const invoice = await db.invoice.findFirst({ where: { id: req.params.id, user_id: userId } });
// The header is untrusted. Set it to the victim's ID and the query passes.

The right shape is to scope the query itself by the authenticated user’s ID — sourced from the verified session, never from a request-controlled value — and return 404 (not 403) on a mismatch so the API doesn’t reveal whether the resource exists for someone else.

Per-stack fix patterns

The bug repeats across stacks; the safe pattern looks different per ORM and framework. Same root cause; different ergonomics for closing it.

The pattern that does not work in any stack: “we’ll remember to add the check on every route.” You will not. The AI will not. The check has to live somewhere structural — in the ORM helper, in the RLS policy, in the framework convention — not in every route handler.

A specific incident — anonymized

Multi-tenant project management product. Auth was Supabase, RLS was enabled on projects with using (auth.uid() = owner_id). The benchmark scenario at gapbench.vibe-eval.com/site/multi-tenant-saas/ reproduces this exact shape.

The team had also added a Next.js API route at /api/projects/[id]/export that exported the project as JSON for backup. The export did some join logic the AI wrote with the service-role key because the joins were complicated and the pattern that came back was “use service-role to do the heavy lift.” With service-role, RLS does not apply. The API route did check req.session.userId against the project’s owner — but only against the project’s owner. It did not check the project’s tenant. So a user from tenant A who knew (or guessed) a project ID from tenant B could call the export endpoint, the ownership check matched (they owned a project with that ID — in their own tenant), and the export ran against the service-role-scoped data.

We found it because the BOLA suite includes a cross-tenant ID enumeration probe. The fix was to scope the query by tenant inside the Edge Function and add an integration test that hit the endpoint with another tenant’s ID and asserted 404. The bug had been live for four months.

The takeaway: RLS on the table does not save you when the API route is using service-role. The application-layer check has to mirror what RLS would have enforced, plus any cross-cutting scoping (tenant, organization, workspace) the application model adds.

Methodology

Sample. All 1,341 apps in the corpus that exposed at least one path matching /api/<resource>/:id patterns or equivalent (Supabase PostgREST, Hasura GraphQL, Firebase Functions). 173 apps with no CRUD surface (static sites, V0 component libraries) were excluded.

Probe. For each candidate route, we created two test users, had user A produce a resource, then had user B attempt to read, modify, and delete user A’s resource. A response containing user A’s data classified as BOLA. A 401 / 403 / 404 classified as safe. Ambiguous responses (e.g. empty 200) were manually verified.

De-duplication. A route is counted once per app per verb. An app with the same BOLA on five resources still counts as five findings.

Limits. We tested only routes that were discoverable via crawling and OpenAPI introspection. Routes that require a specific request body to enumerate (graph mutations, RPC-style endpoints with unguessable names) are likely under-counted.

Calibration against ref0. Every probe in the BOLA suite is also run against ref-rls — a deliberately clean reference scenario where the same shape of CRUD is correctly scoped on auth.uid(). Any probe that fires on ref-rls is, by construction, a false positive — and the rule gets killed. The aggregate counts in the tables above are net of false-positive elimination via the reference site.

Reproduce on the public benchmark

Every detection class above maps to a scenario on gapbench.vibe-eval.com. The scenarios are live; the curl commands run today.

For the full anatomy of how the bug ends up shaped this way and how each fix pattern looks per stack, see the companion pattern walkthrough: BOLA in AI-generated CRUD.

How to reproduce

The full BOLA enumeration is part of the VibeEval scan, which creates two sandboxed test users and runs the cross-user matrix automatically. Free single-shot probes are available via the Vibe Code Scanner with reduced coverage.

Citations

VibeEval. Broken Object-Level Auth in AI-Generated CRUD: A Quantitative Study. May 2026. https://vibe-eval.com/data-studies/bola-in-ai-generated-crud/

Related

• Pattern walkthrough: BOLA in AI-generated CRUD — the missing ownership check
• Pattern walkthrough: Mass assignment — when the AI hands the user is_admin: true
• Pattern walkthrough: The Supabase service-role key in your frontend bundle (because service-role bypasses the RLS layer that would have caught BOLA)
• Data study: 2026 AI App Security Benchmark
• Data study: Supabase RLS in the Wild
• Data study: Where Vibe Coders Leak Their Keys
• Guide: Solo Founder Pre-Launch Security Checklist
• Tool: Vibe Code Scanner