What is IDOR / BOLA?

IDOR / BOLA in plain English

IDOR stands for insecure direct object reference – an unprotected, direct pointer to a data object. BOLA stands for broken object level authorization – a faulty permission check at the level of individual objects. Both terms describe the same problem. A web application or an application programming interface (API) returns records such as invoices, orders, or profiles based on an identifier. In doing so, it doesn’t check whether the person making the request is actually allowed to see that record.

A comparison: at a theater coat check, you hand over your ticket with the number 57 and get your coat back. If you say “number 58” instead, you’re handed a stranger’s coat, no questions asked. The attendant only looks at the number – not whether it belongs to you.

How an IDOR attack works

1. The attacker uses a perfectly normal account, for example as a customer of an online shop.
2. They observe the requests their browser or app sends to the server – for example, a call to “/api/invoices/1001” that retrieves an invoice.
3. They change the identifier to 1002, 1003, and so on.
4. If the server only checks whether someone is logged in, but not whether the invoice belongs to that account, it hands out other people’s data. With a simple script, large amounts of data can be retrieved this way in a short time.

Depending on the function, an attacker can not only read other people’s data, but also change or delete it. Random-looking identifiers make guessing harder but don’t solve the problem: they can still turn up in links, logs, or other responses from the application.

Automated scanners often miss this vulnerability. They have no way of knowing which invoice belongs to which account – a response containing someone else’s data looks completely normal to them. In the OWASP API Security Top 10, a globally used list of the most important API risks, BOLA ranks first. In web applications, IDOR falls under the category “Broken Access Control,” which also ranks first in the current edition of the OWASP Top 10.

A practical example

Here’s a typical scenario: A property management company offers tenants an app where they can report damage and download their utility statements. In the API penetration test, the testing team works with two test accounts and discovers that the download interface only checks whether someone is logged in. Using the number of another tenant’s statement, the team can retrieve it – including name, address, and bank details.

The app itself never offers this option; the flaw lies solely in the API. The team reports the critical finding immediately, and the development team adds a central check that verifies, for every request, that the record belongs to the logged-in account.

Why does this matter for businesses?

IDOR vulnerabilities are easy to exploit and often affect sensitive data. If personal data reaches unauthorized persons, this generally constitutes a personal data breach under the GDPR. It must be reported to the supervisory authority without undue delay and, where feasible, within 72 hours. The only exception is when the breach is unlikely to result in a risk to the individuals affected.

The vulnerability is particularly sensitive on platforms shared by many customer companies. If one customer can see another customer’s data, trust in the entire platform is quickly at stake. In addition, modern web and mobile apps rely heavily on APIs that process identifiers directly. Technically, IDOR is usually a form of horizontal privilege escalation: one account accesses the data of another account with the same level of privileges.

How to protect your organization

• Check every access: On the server side, verify for every retrieval, change, and deletion whether the logged-in account is allowed to use the record.
• Centralize the rules: Keep the authorization logic in one place instead of re-implementing it in every function. Principle: deny access unless it is explicitly allowed.
• Don’t treat identifiers as protection: Random IDs are useful, but they don’t replace an authorization check.
• Test automatically: Add test cases to your automated tests in which a second account deliberately tries to access other users’ records.
• Detect anomalies: Log unusually high numbers of requests for consecutive identifiers and limit the number of requests.
• Have it tested manually: A penetration test with several accounts per role specifically targets such flaws – typically as a gray-box test.

How Rootsektor can help

In our API penetration test, we systematically test your interfaces with several accounts per role – including across different customer companies on the same platform. Our testing is guided by the OWASP API Security Top 10. We test web applications with a login as part of our penetration testing for Web Applications & Online Shops. We report critical vulnerabilities immediately – during the test, by phone or email to the agreed contact person. You can get a fixed-price quote after scoping via our Pentest Quote page.