BOLA, BOPLA and BFLA: The 3 Flaws That Rule APIs in 2026

The OWASP API Top 10 opens with BOLA, BFLA and BOPLA — three classes of authorization flaw that have dominated the list since 2019 and keep dominating in 2026. That's no coincidence. They are the 3 classes that show up most often in international bug bounty programs, that most often compromise B2B SaaS platforms in production, and that no scanner catches properly.

This article explains each one in depth, shows how a real researcher attacks them, and what a product team needs to do to block them.

The context: the 2023 API Top 10

In 2023 OWASP updated the API Top 10. The first three positions are, in order:

Four of the top 5 are authorization flaws. API security in 2026 is, above all, about getting authorization right.

BOLA — Broken Object Level Authorization

What it is

Historically known as IDOR (Insecure Direct Object Reference). It happens when an API endpoint receives an ID and returns the matching object without checking whether the authenticated user is allowed to access that specific object.

Classic example

Endpoint: GET /api/orders/12345

The victim legitimately opens order 12345. The attacker changes it to 12346, 12347, and sees other users' orders. In B2B SaaS this is catastrophic — it breaches the contract, violates data protection laws such as Brazil's LGPD, and kills the renewal.

Modern variants (that scanners miss)

• UUID guessing — “UUIDs are safe,” people say. They're not. UUIDs frequently leak in logs, in emails, in headers, in shared URLs. The attacker collects UUIDs through OSINT and tries each one.
• Indirect via a secondary parameter — the endpoint GET /api/me/orders looks safe because it uses “me.” But if the backend reads X-User-Id from the header, the attacker changes that header and pulls other users' orders.
• Search-based BOLA — a search endpoint returns a list. The filter ?owner=<id> has no ACL. The attacker searches by owner=another-tenant and sees everything.
• BOLA in destructive actions — DELETE /api/users/123 without checking whether user 123 belongs to the requester's tenant. The attacker deletes users from other tenants.

Why scanners miss it

A scanner has no idea who should have access to what. It sees the endpoint return a 200 with JSON and marks it as OK. Detecting BOLA requires creating two users in different contexts and attempting cross-access — manual work.

How to block it

• Every endpoint must check authorization at the object level, not just authentication
• Standard pattern: extract the tenant_id from the JWT session, compare it with the tenant_id of the requested object
• Centralize authorization logic in middleware or a policy engine (Casbin, OPA, Cedar)
• Automated tests: for each endpoint, create 2 users and attempt cross-access

BFLA — Broken Function Level Authorization

What it is

It happens when a user without the right role manages to run a function that should be restricted to other roles. It usually affects administrative endpoints.

Classic example

The endpoint DELETE /api/admin/users/123 should only be reachable by admins. But the frontend merely hides the button from regular users — the backend never validates the role. A regular user calls the endpoint via curl and deletes users.

Modern variants

• HTTP method confusion — the endpoint POST /api/users/{id} is valid for editing your own record, but PUT or PATCH on the same path is accepted without extra validation, and PATCH allows more fields
• Override headers — X-HTTP-Method-Override: DELETE on a POST request tricks poorly configured middleware
• “Parallel” endpoints — /api/v2/users/{id} has a new ACL, /api/v1/users/{id} still exists and has none
• Admin endpoints without a prefix — /api/users/promote with no “admin” prefix slips past code review

How to block it

• Default deny: no endpoint is public until it is explicitly authorized
• RBAC or ABAC implemented in middleware, not in each individual handler
• Structured logs of every denied authorization (for detection)
• Matrix testing: for each endpoint × each role, validate the expected behavior

BOPLA — Broken Object Property Level Authorization

What it is

BOPLA is the evolution of mass assignment + excessive data exposure. It comes in two flavors:

1. Excessive data exposure: the endpoint returns more object properties than the user should see. The frontend filters them out on display, but the API returns everything.
2. Mass assignment: the endpoint accepts more writable properties than the user should be able to modify.

Classic example — excessive data exposure

GET /api/users/123 returns { name, email, role, salary, ssn }. The frontend only shows name and email. But any user with browser DevTools sees the full object.

Classic example — mass assignment

PATCH /api/users/me accepts a JSON body and spreads it into user.update(req.body). The user sends { "role": "admin", "tenant_id": "other" }. The backend saves it. Immediate escalation.

Modern variants

• Nested mass assignment — PATCH /api/posts/123 accepts author.role; the ORM updates not only the post but the author too
• GraphQL field spreading — the query returns more fields than the resolver assumes; the frontend only tested the fields it requested, but the attacker asks for all of them
• Update via include — JSON:API-style APIs let you “include” related resources; updates can cascade
• Whitelist drift — the allow-list was written in January, new fields were added to the model in February, and nobody updated the whitelist

How to block it

• Define explicit DTOs (Data Transfer Objects) for input and output, separate from the domain model
• Whitelist of updatable properties (allow-list, never block-list)
• In GraphQL: use @auth directives in the schema, with per-field permissions
• For output, explicit projection (specific SELECT, not SELECT *)
• Mandatory code review whenever the domain model changes

The combined attack: chaining BOLA + BOPLA

The most devastating exploit combines BOLA and BOPLA:

1. BOLA lets the attacker list other tenants' IDs (e.g., GET /api/users?search=*)
2. BOPLA lets the attacker edit a sensitive field on another tenant (e.g., PATCH /api/users/<other_tenant_user> with email changed to the attacker's)
3. The attacker uses “forgot password” — the reset link arrives in their inbox
4. Full account takeover of any account on the platform

This pattern showed up in public bug bounty findings in 2023–2024 paying between $5,000 and $25,000 per finding. In B2B SaaS, it's the kind of bug that ends a contract with an enterprise customer overnight.

How a serious pentest attacks this

Adequate coverage requires:

• Auth Matrix — systematic mapping of endpoints × roles × verbs. No Vuln's proprietary tooling automates this across 200+ endpoints
• 2 accounts in different tenants — the basic prerequisite. Without them, you can't test cross-tenant access
• Response diffing — across different roles, to see which fields only appear for an admin
• Mass Assign Tester — property fuzzing on PATCH/PUT
• IDOR Wildcard Probe — rotating IDs in different formats (numeric, UUID, slug, base62)
• A final manual review, because all automation has false negatives

Conclusion

BOLA, BFLA and BOPLA are not rare bugs. They are the 3 most common bugs in production APIs in 2026. And they are invisible to scanners. If your API pentest doesn't explicitly mention coverage of these 3 classes, with a role × endpoint test matrix, it's incomplete — regardless of the price.

Correct coverage is skilled manual work. It's exactly the kind of testing that separates “a pentest with a pretty PDF” from “a pentest that actually protects you.”