Broken Object Level Authorization

When you log into an online shop and look at your invoice, your browser sends a request to the shop’s server. This request often contains a number, for example “invoice 5012”. The server is now supposed to check two things: Are you really logged in, and does this invoice actually belong to you? Broken Object Level Authorization refers to the flaw where only the first check takes place while the second is missing. If you manually change the number to 5013, the server delivers another customer’s invoice. The English name essentially means: the access control for individual data records is broken.

Why a wrong number can empty entire databases

This vulnerability has topped the best-known list of flaws for programming interfaces for years, the OWASP API Security Top 10. OWASP is a non-profit organization that collects and rates security problems in software. The reason for the top spot is simple: the flaw is common, easy to find, and causes major damage.

What’s especially unpleasant is that the attack requires no special tools. No password cracking and no malicious code are needed. A normal user account is enough, along with the willingness to increment a number in the address bar. Anyone who automates this can download hundreds of thousands of records within a few hours.

In practice, this has already leaked account balances, medical records, ID photos, and chat histories. For companies, this is not just reputational damage. In the EU, the General Data Protection Regulation can result in fines running into the millions if personal data was inadequately protected.

Checking identity is not the same as checking authorization

Software distinguishes between two steps. Authentication establishes who you are, usually via login and password. Authorization establishes what you are allowed to see and change. With this vulnerability, step one works flawlessly, while step two is simply forgotten for individual objects.

A comparison makes this tangible. A hotel checks your ID at the reception desk and lets you in. But if every room door afterward opens with the same key, the ID check does little good. This is exactly how a server behaves that only checks the login and then hands out every record.

This can be prevented with a rule in the code: before outputting any record, check whether it belongs to the logged-in account. Hard-to-guess identifiers, such as long random strings instead of sequential numbers, also help. However, this alone is not a solution, only an obstacle. Security through obscurity is considered a fallacy, because such identifiers still become known via links, log files, or other users.

From banking apps to AI assistants

Applications that load data via an interface rather than delivering complete pages are especially affected. This applies to almost every modern mobile app, as well as web portals of banks, government agencies, and clinics. In security advisories, the flaw also appears under its older name, Insecure Direct Object Reference, or IDOR for short. At its core, it means the same thing.

You typically encounter the term in the news after a data breach. When reports say customer data was “freely accessible without any hacking”, this exact vulnerability is often behind it. Companies now pay rewards to security researchers who report such flaws. Such bug bounty programs are cheaper than a leak that makes headlines.

The topic is gaining new significance through AI assistants that query interfaces autonomously on behalf of users. Such an assistant tries out requests in large numbers and without hesitation. If the authorization check is missing, it can unintentionally pull other people’s data into a response. That’s why object-level control is one of the points that should be checked early on in AI products.