OWASP API Security Top 10: Testing BOLA, BFLA and Property-Level Authorisation
Three of the ten API Top 10 categories are authorisation failures, and they account for most serious API findings. How BOLA, BOPLA and BFLA are each tested, the account matrix that covers them, what evidence a finding needs, and how to fix the pattern rather than the instance.
API Security
Three of the ten categories in the OWASP API Security Top 10 are authorisation failures, and between them they account for most of the serious findings in a real API engagement. Here is how each one is tested, what evidence a finding needs, and how to fix it so it stays fixed.
In short. BOLA asks can this user reach that object? BOPLA asks can this user read or write that field? BFLA asks can this user call that function? None of the three can be found by a scanner, because a scanner does not know who is supposed to see what. They are found by a tester holding two accounts and a list of every endpoint that accepts an identifier.
Why authorisation dominates API findings
A web application has a user interface between the user and the data. It hides buttons, greys out fields and only shows the records a person is entitled to. An API has none of that. Every endpoint is reachable by anyone who can form a request, and the only thing standing between one customer's data and another's is whether the server checks, on every call, that the caller is entitled to what they asked for.
That check is easy to write once and easy to forget on the fortieth endpoint. It is also invisible to automated tools: a scanner can tell you an endpoint returned 200, but it cannot tell you the 200 contained somebody else's invoice. So authorisation failures are simultaneously the most common serious API finding and the one least likely to have been caught before a manual tester arrives.
The current edition of the OWASP API Security Top 10 is 2023, and it has three authorisation categories: API1 Broken Object Level Authorization, API3 Broken Object Property Level Authorization, and API5 Broken Function Level Authorization. The rest of this article works through those three in the depth a test plan needs, then covers the other seven briefly.
The 2023 list at a glance
| ID | Category | The question it asks |
|---|---|---|
| API1 | Broken Object Level Authorization | Can this caller reach that specific object? |
| API2 | Broken Authentication | Is the caller who they claim to be? |
| API3 | Broken Object Property Level Authorization | Can this caller read or write that specific field? |
| API4 | Unrestricted Resource Consumption | Can a caller make the API do unbounded work? |
| API5 | Broken Function Level Authorization | Can this caller invoke that function at all? |
| API6 | Unrestricted Access to Sensitive Business Flows | Can a flow be automated in a way that harms the business? |
| API7 | Server Side Request Forgery | Can a caller make the server fetch a URL of their choosing? |
| API8 | Security Misconfiguration | Is the platform set up the way it was meant to be? |
| API9 | Improper Inventory Management | Do you know every version and environment that is live? |
| API10 | Unsafe Consumption of APIs | Do you trust upstream APIs more than you should? |
API1: Broken Object Level Authorization
Usually shortened to BOLA, and known in older material as IDOR. An endpoint takes an identifier, looks up the object, and returns it, without confirming the caller is entitled to that particular object. Change the identifier in the request and you get somebody else's record. It is the most common serious API finding there is, and almost every non-trivial API has at least one instance the first time it is tested.
How it is tested
Step 1 — Two accounts, same role
Account A and Account B, both ordinary users, each with objects they own. This is the minimum. Without two accounts, BOLA cannot be tested at all, and missing test accounts is the single most common reason an API engagement stalls on day one.
Step 2 — Enumerate every endpoint that accepts an identifier
Path parameters, query parameters, request-body fields, headers. Include identifiers that name a parent object as well as the target: an order ID inside a request for a line item is still an identifier.
Step 3 — Swap, across every HTTP method
As Account A, request Account B's identifier on each endpoint. Test GET, PUT, PATCH and DELETE separately, because the read path is often protected and the write path is not. A 200 with B's data, or a 204 that changed B's object, is the finding.
Step 4 — Try the indirect routes
Nested objects reached through a parent (/users/A/orders/B-order), bulk endpoints that accept arrays of IDs, export and report endpoints, search filters that take an owner field, and any endpoint that takes the identifier of a related object such as an attachment or a comment.
Step 5 — Test the identifier format, not just the value
Sequential integers are the easy case. UUIDs are still tested: they are frequently exposed elsewhere in the API, in shared links, or in exported files, and an unguessable identifier is not an access control. If the identifier is encoded or signed, test whether the server actually verifies it.
What the finding needs to show
Two request-and-response pairs, side by side: Account A requesting its own object and receiving it, then Account A requesting Account B's object and receiving that too. Both with the authenticated session visible, both with the full response body, both timestamped. A screenshot of a single 200 proves nothing on its own, because the reviewer cannot tell whose data it is.
How to fix it so it stays fixed
- Enforce ownership at the data-access layer, not in each controller. A check that has to be remembered on every new endpoint will be forgotten on one of them. A repository method that takes the caller's identity and scopes every query to it cannot be forgotten.
- Check on every request, including writes. The read path being protected tells you nothing about PATCH.
- Do not rely on identifiers being hard to guess. Switching to UUIDs reduces enumeration; it does not add an access control.
- After fixing, enumerate. BOLA is almost never isolated to the endpoint where it was found. Test every identifier-accepting endpoint again, and where the cause sits in the code, secure code review is faster than black-box retesting for finding the siblings.
- Check the logs. If the endpoint was live, ask whether it was exploited. That is a potential breach-notification question, not only a bug.
API3: Broken Object Property Level Authorization
BOPLA is BOLA one level down. The caller is entitled to the object, but not to every property on it. It merges two older categories: excessive data exposure, where the API returns fields the client never displays and the user should never see, and mass assignment, where the API accepts fields on write that the user should never be able to set.
How it is tested
| Direction | Test | What a finding looks like |
|---|---|---|
| Read | Capture the full JSON of every response and diff it against what the client actually renders. Anything the UI never shows is a candidate. | A user profile response that includes another user's email, internal role flags, password hashes, internal identifiers, or the price a competitor paid. |
| Write | On every create and update endpoint, send fields that appear in the read response but not in the client's form: role, isAdmin, verified, price, ownerId, createdAt, balance. | The field is accepted and persisted. Confirm by reading the object back. |
| Nested | Send objects where a scalar was expected, or a related object inline where the API normally expects a reference. | The framework binds the nested object and writes through to a related record. |
How to fix it
- Explicit allowlists in both directions. A response type that names the fields it returns, and a request type that names the fields it accepts. Never serialise the database model directly, and never bind the request body straight onto it.
- Different types for different callers. The admin view of a user and the self-service view are two response types, not one type with fields removed at render time.
- Reject, do not ignore. An unknown field in a request should be an error, because silently dropping it hides the attempt from your logs.
API5: Broken Function Level Authorization
BFLA is about the function rather than the object. An ordinary user can call an endpoint that should be restricted to administrators or to a different role. It is what happens when authorisation is implemented by not showing the button, and the endpoint behind the button is left unguarded.
How it is tested
Vertical — call the privileged function as an ordinary user
Map every endpoint an admin can reach, then call each one with an ordinary user's session. Guess the ones you cannot see: /admin/, /internal/, /manage/, the same resource path with a different verb, and documented endpoints that the client never calls.
Method tampering — same path, different verb
If GET /users/42 is permitted, try DELETE /users/42 and PUT /users/42. Route-level authorisation is often declared per method and forgotten on the ones the client does not use.
Horizontal — a different role, same level
A support agent's functions called as a finance user, or a tenant administrator's functions called as a different tenant's administrator. Needs a third account, which is why three accounts is the comfortable minimum for an API engagement rather than two.
Client-side hints
Mobile apps and single-page applications ship their route tables and feature flags to the client. Read the compiled application for endpoints and role names it knows about but never shows you. Mobile application testing is a productive source of API endpoint lists for exactly this reason.
How to fix it
- Deny by default, at the routing layer. Every route requires an explicit grant. A route with no declared policy fails closed.
- One authorisation module. Roles and permissions checked in one place that every controller calls, rather than a conditional at the top of each handler.
- Administrative functions on a separate surface where practical. A separate host or path prefix with its own network controls is a second layer, not a replacement for the first.
The test matrix
All three categories reduce to the same exercise: a grid of callers against targets, filled in cell by cell. The rows are the accounts you hold, the columns are every endpoint that accepts an identifier or performs a privileged function, and each cell records what happened when that account called that endpoint with a target it should not reach.
| Account | Own object | Other user's object | Admin function | Other tenant's function |
|---|---|---|---|---|
| Unauthenticated | must be 401 | must be 401 | must be 401 | must be 401 |
| User A | 200 expected | 200 = BOLA | 200 = BFLA | n/a |
| User B | 200 expected | 200 = BOLA | 200 = BFLA | n/a |
| Tenant-2 admin | n/a | 200 = BOLA | 200 expected (own tenant) | 200 = BFLA |
| Every cell | Repeat per HTTP method. Record the full request and response for every unexpected 2xx. | |||
On test accounts. Two ordinary users is the absolute minimum. Two ordinary users, one administrator and one user in a second tenant is what lets every cell above be filled. Have them working on day one, with objects already created under each. The most common cause of a delayed API engagement is not a difficult finding; it is a tester waiting for a second account.
The other seven, briefly
| Category | What the tester does | Tooling helps? |
|---|---|---|
| API2 Broken Authentication | Token lifetime and revocation, weak or missing signature checks on JWTs, credential stuffing protection, password reset flows, whether an API key alone identifies a user. | Partly |
| API4 Unrestricted Resource Consumption | Missing rate limits, unbounded page sizes, expensive queries reachable without limits, file upload size, and third-party costs (SMS, email) triggered per request. | Partly |
| API6 Sensitive Business Flows | Whether a purchase, booking, referral or vote can be scripted at a rate or scale that harms the business. Needs an understanding of what the business considers harm. | No |
| API7 Server Side Request Forgery | Every parameter that takes a URL or hostname: webhooks, imports, image fetchers, PDF renderers. Targets are internal services and cloud metadata endpoints. | Partly |
| API8 Security Misconfiguration | Verbose errors, CORS policy, missing security headers, TLS configuration, debug endpoints, default credentials on supporting services. | Yes |
| API9 Improper Inventory Management | Old versions still live (/v1/ beside /v3/), staging and pre-production hosts reachable, undocumented endpoints found in client code or archived documentation. | Yes |
| API10 Unsafe Consumption of APIs | How your API handles what upstream APIs return: unvalidated redirects, unbounded responses, injection through data you trusted because it came from a partner. | Partly |
Where automated tools stop
Dynamic scanners are good at API8 and API9. They find the debug endpoint, the missing header, the old version left running. They can contribute to API2, API4 and API7 given the right configuration. They cannot find API1, API3, API5 or API6, because each of those requires knowing what the caller is supposed to be allowed to do, and no tool knows your authorisation model.
This is why an API engagement that reports only what a scanner reported has tested the easy seventy percent and skipped the part where the serious findings live. When you compare quotes, ask how many accounts the tester wants and how they will test object-level authorisation. A vendor who does not ask for a second account is not going to test for BOLA.
Frequently Asked Questions
Click any question to expand the answer.
QIs BOLA the same as IDOR?
In practice yes. IDOR, insecure direct object reference, is the older name from web application testing. The API Security Top 10 uses Broken Object Level Authorization because the failure is the missing check, not the fact that the reference is direct. Making identifiers indirect or unguessable does not fix it.
QWe use UUIDs. Are we protected against BOLA?
No. A UUID makes the identifier hard to guess; it does not make the endpoint check ownership. UUIDs leak constantly: in other API responses, in shared links, in exported files, in browser history, in support tickets. Treat any identifier as public and check authorisation on every request regardless.
QHow many test accounts does an API test need?
Two ordinary users is the minimum, and without two BOLA cannot be tested at all. Two ordinary users plus one administrator plus one user in a second tenant is what allows every authorisation case to be covered. Have them ready with data under each before testing starts.
QCan a scanner find these?
Not the three authorisation categories. A scanner can see that a request returned 200; it cannot know that the 200 should have been a 403, because it does not know your authorisation model. Some tools can be configured with two sessions and will flag responses that are identical across them, which is a useful hint, but the judgement about what each user is entitled to is still manual.
QDoes this apply to GraphQL and gRPC?
Yes, and often more so. GraphQL lets the client name the fields it wants, which makes property-level authorisation the central problem rather than a secondary one, and nested resolvers each need their own ownership check. gRPC services frequently rely on network position for authorisation. The categories are the same; the request shapes differ.
QWe found one BOLA. How worried should we be?
Assume there are more. BOLA is a pattern failure: the check was left to individual endpoints, and one being missing means the pattern permits missing checks. Enumerate every identifier-accepting endpoint and test each, then move the check to a layer where it cannot be omitted. Then look at access logs for the affected endpoint, because if it was reachable in production the question of whether it was used is a breach question.
QIs there a newer edition than 2023?
Not at the time of writing. The OWASP API Security project lists 2019 and 2023 editions, and 2023 is current. Check the project site before relying on this, because the list is periodically revised.
QHow does this relate to the OWASP Top 10 for web applications?
They are separate lists from separate OWASP projects. The web application list's A01 Broken Access Control is the broad category; the API list breaks the same problem into object-level, property-level and function-level because in an API those three fail independently and are tested differently. Where an API is assessed under a programme such as CASA, the requirement set it maps to is ASVS rather than either Top 10.
QOur mobile app's API is not documented. Can it still be tested?
Yes, and undocumented APIs are where authorisation findings concentrate. The endpoint list is recovered from the compiled application and from proxying its traffic. That recovered list is often longer than the documented one, which is itself an API9 finding.
QWhat should a BOLA finding in a report contain?
The endpoint and method, the two accounts used, the request from Account A for Account B's object, the full response showing B's data, timestamps, and a statement of which other endpoints were tested for the same pattern. A finding that shows one 200 with no indication of whose data it contains has not demonstrated anything.
Related reading
On where the hours in a web and API engagement actually go, and why access control absorbs most of them: web application penetration testing with AI in 2026. On the code-level failures behind these findings: secure coding practices for developers. For the wider testing landscape, the complete guide to application security testing.
If your API is being assessed under a formal programme, CASA covers web applications and web-accessible APIs, and the self-assessment and evidence guide includes a worked example of object-level access control evidence.
About Adayptus
Adayptus Consulting Private Limited is an application security testing firm based in Noida, India. We have been doing web, mobile and cloud security testing since 2018.
Our API penetration testing covers REST, GraphQL, SOAP, gRPC and WebSocket services, and the authorisation matrix above is the core of how we test them. Every delivered finding is reproduced by hand with the request and response pairs shown, and a remediation retest is included once you have made the changes.
What we can do for you:
- API penetration testing. Manual, account-based testing against the OWASP API Security Top 10, with the object-level, property-level and function-level matrix filled in for every identifier-accepting endpoint. Usually alongside web application testing or mobile application testing for the clients that call it.
- Fixing the pattern, not the instance. Where a BOLA or BFLA finding points at a missing layer rather than a missing line, secure code review finds the siblings faster than black-box retesting, and threat modelling puts the authorisation boundary where it belongs before the next forty endpoints are written.
- Evidence you can hand on. Findings written so a developer can reproduce them and an auditor can read them, with the request and response pairs that make the difference between a claim and a demonstration.
Attribution and source
Category names and identifiers in this article are from the OWASP API Security Top 10, 2023 edition, published by the OWASP Foundation under Creative Commons Attribution-ShareAlike 4.0 International. The testing methodology, the test matrix and the remediation advice are our own.
The list is revised periodically. Confirm the current edition at the project site before relying on the category numbering.
Adayptus Consulting
Application Security Testing, Adayptus
Adayptus Consulting Private Limited is an application security testing firm based in Noida, India, working across web, mobile, API and cloud security testing since 2018.
On This Page
- Why authorisation dominates API findings
- The 2023 list at a glance
- API1: Broken Object Level Authorization
- API3: Broken Object Property Level Authorization
- API5: Broken Function Level Authorization
- The test matrix
- The other seven, briefly
- Where automated tools stop
- Frequently Asked Questions
- Related reading
- About Adayptus
- Attribution and source
