How to Test for Broken Object Level Authorization: The 5 Requests That Prove It
Broken object level authorization (BOLA) occurs when an application verifies who you are but never checks whether you own the object you're requesting, so a logged-in user can read or modify another user's data by changing an ID in the request. OWASP ranks it the top API security risk. Test it by replaying requests as two accounts and comparing responses.
Your API returned a 200. The user is logged in, the token is valid, and the record came back. That is the moment a broken object level authorization flaw stops being theoretical, and it is also the moment most test plans stop looking.
The problem is current, and it is not exotic. On October 8, 2026, JPCERT/CC issued an alert on a sharp rise in personal data leaks at Japanese organizations, with attackers abusing mobile app APIs and exploiting known flaws in the open-source Metabase analytics platform [4]. No novel zero-day was required: the Metabase flaws were known vulnerabilities, and the abused API endpoints were doing the oldest thing in API security, trusting the object ID the client hands them.
In our web application and API tests, the BOLA we see most often is not a missing check. It is a check that exists in one controller and was forgotten in every endpoint added after it. The app's release history tells you exactly when it started leaking.
Clone Systems' position: organizations test authentication thoroughly and object-level authorization almost never, because both automated scanners and a large share of manual tests verify that a user can log in, not what that user can touch after logging in. The control usually exists in the codebase already. What is missing is the test, and the test takes five requests.
What Is Broken Object Level Authorization, and Why Do Scanners Miss It?
Broken object level authorization is a flaw where the application authenticates the user but never enforces ownership of the object the request references, so any logged-in user can reach records that belong to someone else. It is the top entry, API1:2023, in OWASP's API Security Top 10, and its parent category, broken access control, is the number one entry in OWASP's 2025 Top 10 [1][2].
The scale of the data is blunt. OWASP's 2025 Top 10 methodology found some form of broken access control in 100 percent of the applications tested, with 1,839,701 total occurrences in the contributed data [2]. In 2025 penetration tests, improper access control was the third most frequent finding at 11.8 percent, and the authors of that data state the reason directly: a vulnerability scanner alone cannot detect broken access control, because it is business logic [3].
What a scanner can and cannot verify
A scanner can tell you which endpoints exist, which return data, and which reject unauthenticated access. It cannot tell you whether account B should have been allowed to read account A's invoice, because that question has no CVE signature, no version string, and no response code to match against. The test has to ask the application a question about ownership, and only a test designed around two accounts can ask it. Our authenticated web application scanning work exists for the same reason: a scan that never logs in is describing a login form, not an application.
How to Test for Broken Object Level Authorization
Here is the test we run. We call it the Clone Systems BOLA 5-Request Test. It takes one pair of test accounts and about an hour, and it produces evidence either way.
- Baseline (request 1). Log in as account A and fetch your own object, for example GET /api/invoices/INV-1042. Record the full response, including headers and fields.
- Swap the ID (request 2). Log in as account B and send the identical request. A correct application answers 403, 404, or an empty result. A 200 with account A's data is BOLA, and you can stop here.
- Try the write (request 3). As account B, send a PUT or DELETE against account A's object ID. Authorization that works for reads and fails for writes is the most common partial fix we see, because teams patch the read handler and forget the mutation handlers.
- Walk the ID space (request 4). Try a small batch of nearby or swapped identifiers. Sequential IDs, predictable timestamps, and object IDs handed out in list responses are all exploitable patterns, and the pattern tells your developers whether the fix is a check or a redesign of the reference itself.
- Change the channel (request 5). Repeat request 2 against the raw API instead of the web front end, and against a mobile endpoint if you have one. OWASP's guidance is direct on this point: access control must be enforced in trusted server-side code, not in the front end, because the attacker's browser is not the attacker's constraint [1].
If your current test plan covers requests one and two, it is a start. If it covers only request one, the finding will come from an attacker's afternoon, not from your report.
When the test is part of a broader scope, the question for any vendor is whether they run object-authorization checks as a designed procedure or as a side effect of clicking around. Our credentialed and web application scanning pairs authenticated scanning with a manual authorization pass, so the endpoints your scanner can see are the endpoints that get tested for ownership.
BOLA vs IDOR: Same Flaw, Two Names?
Yes, with one important extension. The older term, insecure direct object reference (IDOR), describes the case where the object reference is the identifier itself and the client swaps it. OWASP's API Security Top 10 uses BOLA because the flaw is not limited to direct references: any client-controlled reference to an object, including a token, a state parameter, or a JWT claim, qualifies when the application does not verify that the requester owns the object [1]. OWASP's 2025 Top 10 still lists "permitting viewing or editing someone else's account by providing its unique identifier (insecure direct object references)" as a common form of broken access control, so both terms remain in active use [2]. In test reports, write both: BOLA (IDOR).
Why Does the Fix Keep Failing?
The root cause is structural. The application accepts an object reference from the client, so every endpoint that takes one inherits the risk, and the endpoint that leaked is rarely the only one. OWASP's prevention guidance points at the actual fix: enforce record ownership in the domain model, deny by default, and keep the check in trusted server-side code [1][2].
In our retest work, the pattern repeats. The reported endpoint gets patched, and three sibling endpoints with the identical flaw stay open, because the fix went into a single handler instead of the shared helper. When a client reports a BOLA, the first question is not "which endpoint." It is "where is the ownership check, and does every endpoint that takes an object ID go through it?"
Test Your Own App: The 3-Question Ownership Check
You do not need a test environment for this. If you cannot answer the three questions below, that is already a finding, and it is the cheapest one you will find all year.
- The ownership map. Does the application keep a server-side mapping of which user owns which record, or does it infer ownership from the request?
- The check path. Name the code path where a request's object ID is compared against the session's user. If the answer is "in the controller," ask which controllers, because a controller-level answer is where the sibling endpoints hide.
- The write test. When was the last time you tested a PUT, DELETE, or POST as a second account, not just a GET? Reads get tested; writes get shipped.
How Clone Systems Can Help
- Web application and API penetration testing. Manual, object-aware testing of your authenticated flows: the 5-Request Test plus the sibling endpoint sweep, with evidence for every request (Managed Penetration Testing Services).
- Credentialed and web application scanning. Authenticated scanning that sees the same endpoints your users see, paired with the authorization pass a scanner cannot run (Credentialed Scanning).
- Retest and fix verification. After your team patches, we re-run the same request sequence and confirm the shared helper, not just the reported endpoint, was fixed. Our post on what a retest actually proves covers why that distinction matters.
- Choosing the scope. If you are still deciding what to buy, our 5-signal vendor scorecard separates a test that asks ownership questions from one that simply runs a tool.
Frequently Asked Questions
What is broken object level authorization? Broken object level authorization is a flaw where an application verifies the user's identity but never checks whether that user owns the object named in the request, letting one logged-in user read or modify another user's data. OWASP ranks it the top risk in its API Security Top 10, and its parent category, broken access control, is the number one entry in OWASP's 2025 Top 10.
What is the difference between BOLA and IDOR? IDOR is the older, narrower name for swapping an object identifier in a request to reach another user's record, and BOLA is OWASP's broader term covering any client-controlled object reference, including tokens and state parameters. In practice they describe the same class of flaw, so reports should say BOLA (IDOR) and both readers will understand.
How do you test for broken object level authorization? Create two test accounts, fetch an object as the first, then replay the same request, a write, a batch of identifiers, and a different channel as the second account. Any response that returns or modifies the first account's data is a finding, and the sibling endpoints around it should be tested next.
Can a vulnerability scanner detect BOLA? No, because the flaw is business logic rather than a signature, and the correct and the vulnerable responses can look identical to a scanner. 2025 penetration test data puts improper access control at 11.8 percent, the third most frequent finding, and attributes the detection gap to exactly this point [3].
How do you fix a broken object level authorization vulnerability? Enforce ownership in the domain model or data layer so that every endpoint that accepts an object ID checks it against the session, and deny access by default. Verify the fix with a retest that runs the original request sequence against the sibling endpoints, because a single-handler patch leaves the shared root cause open.
Conclusion
The endpoints behind the leaks in JPCERT/CC's October 2026 alert were not holding the most novel flaws in the wild [4]. They were the ones where a valid token met an object ID and nothing in between asked who owned what. OWASP has now measured this condition in 100 percent of the applications it tested [2], and the test that exposes it takes five requests. Run the 5-Request Test against your own API this week, fix the helper rather than the handler, and if you want the retest to mean something, talk to our team about a penetration test that will run it for you. clone-systems.com
References
[1] OWASP, "API1:2023 Broken Object Level Authorization," OWASP API Security Top 10 2023. https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/ [2] OWASP, "A01:2025 Broken Access Control," OWASP Top 10 2025. Number one entry; found in 100 percent of tested applications; 1,839,701 total occurrences; 3.74 percent average incidence rate. https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control [3] Cobalt, "Comparing the OWASP Top 10 2025 with Real-World Pentest Data," November 7, 2025. 2025 pentest dataset: improper access control the third most frequent finding at 11.8 percent; a scanner alone cannot detect broken access control because it is business logic. https://www.cobalt.io/blog/comparing-the-owasp-top-10-2025-with-real-world-pentest-data [4] The Hacker News, "Japan Sees Sharp Rise in Web Data Leaks Amid Mobile API Abuse and Metabase Attacks," October 8, 2026, reporting the JPCERT/CC alert (details as summarized in the Verisq Intelligence brief of October 8, 2026: https://www.verisq.ai/intelligence/advisories/70254-japan-sees-sharp-rise-in-web-data-leaks-amid-mobile-api-abuse-and-meta). https://thehackernews.com/2026/10/japan-sees-sharp-rise-in-web-data-leaks.html [5] Clone Systems, first-person observation: in our web application and API penetration tests, the most frequent BOLA pattern is an ownership check present in one controller and absent from every endpoint added afterward; on retest, the patched endpoint is usually the reported one, with sibling endpoints sharing the same root cause still open. [6] Clone Systems, "Authenticated Web Application Scanning: What Your Scanner Misses Until It Logs In." https://www.clone-systems.com/blog/authenticated-web-application-scanning-what-your-scanner-misses-until-it-logs-in [7] Clone Systems, "How to Choose a Penetration Testing Vendor: The 5 Signals That Separate a Test From a Report." https://www.clone-systems.com/blog/how-to-choose-a-penetration-testing-vendor [8] Clone Systems, "Why Passing a Penetration Test Retest Isn't the Same as Fixing the Root Cause." https://www.clone-systems.com/blog/why-passing-a-penetration-test-retest-isnt-the-same-as-fixing-the-root-cause [9] Clone Systems, Credentialed Scanning. https://www.clone-systems.com/credentialed-scanning/ [10] Clone Systems, Managed Penetration Testing Services. https://www.clone-systems.com/managed-penetration-testing-services/ [11] Clone Systems, Contact. https://www.clone-systems.com/contact