Understanding Broken Object Level Authorization: The Quiet Access Control Failure Undermining Today’s Apps

Broken Object Level Authorization (BOLA) isn’t new, but it is the most consistently exploited access control failure in modern applications—cloud, API-driven, and even line-of-business systems. And the reason is simple: developers keep trusting the client, and security teams keep assuming authorization is happening somewhere else. Meanwhile, attackers quietly enumerate object IDs, pivot through APIs, and harvest data they were never supposed to see.

If you’ve been a part of the coding and security worlds since the 80’s it’s fascinating how much coding is the same, but how much changes in the context in which code executes can affect the security dynamics.  OWASP API1:2023 – Broken Object Level Authorization – is a great example of what I’m talking about.  For my entire career it’s been best practice – and kind of obvious – to use a unique ID to reference objects (i.e. records, rows).  (You can trace the concept back to at least 1976 in a paper by Owlett and Todd but most of us learn about it from relational db concepts Codd first wrote about a few years later.)  This key is called a surrogate key or synthetic private key.  It can be an integer, UUID or any other sequence of bytes that are unique to that object and never needs to change for the life of that object. 

For decades after that we’ve all been merrily – and securely – referencing object IDs and accepting them as parameters without need to worry about whether the calling function could be trusted because we controlled all the code and the code ran on systems under our control. 

So, we didn’t really need to worry if, say, we were writing a UpdateCustomerPhoneNumber(int CustId, string PhoneNumber) function, whether the customer ID supplied in the parameter reference a customer the end-user had authority to change or not.  We could verify by looking at UI source code that the user had only been presented by accounts they were authorized to update in the first place.  And since we controlled the code and the system it was running on, we could rely on those upstream checks.

(One could argue that the short-lived client/server model of apps was vulnerable to broken object level authorization – and one of my managers in the 90s even made that argument – but the client apps were usually running on a private network on systems managed by the same organization and frankly we weren’t very worried about someone taking the client EXE, de-compiling it and working out how to impersonate the client to fool the server side.  Before we knew it, client/server was replaced by web apps and the front-end even for internal apps was browser-based.)

Until fairly recently, even in web applications it was safe to rely on object IDs and prior authorization checks since all the meaningful programing logic and business rules ran on the application server and there were integrity checks made on session data received back from the web browser client.

My perhaps long-winded point is that there are literally decades of travel worn into the road of passing, receiving and acting up on object IDs without thinking twice about it and you were more or less safe doing so in the coding contexts all that time.

But the context has shifted in today’s code and with it the security dynamics.

The new context that so much code runs in today is the API.  Now, the term API (application programming interface) has been around for decades as well but an API in 2026 is not the same thing as an API from a few years ago.

Today when you talk about APIs you don’t just mean a set of function calls that have been published in such a way that a different program can call them.  The term API has accreted added meaning that that interface is now published to the internet and can potentially be called by anything and anyone (assuming authentication passes). 

With modern APIs there can be no reliance on prior authorization checks having limited which object IDs show up in later calls.

In this real training for free session, I’ll be exploring Broken Object Level Authorization.  I’ll show you coding examples with the vulnerability and then show you how to identify code where this hole is plugged. 

Then we’ll get straight to what matters: how BOLA actually happens in real systems, why traditional security reviews miss it, and what you can do to detect and prevent it across your environment. We’ll walk through concrete examples—REST APIs, GraphQL, microservices, and even older monolithic apps—to show how subtle logic oversights turn into full-blown data exposure.

You’ll learn:

• Why object-level authorization is fundamentally different from role-based access control—and why confusing the two leads to catastrophic blind spots
• How attackers discover and exploit insecure direct object references (IDOR) using nothing more than predictable identifiers and unauthenticated endpoints
• How to instrument your applications, APIs, and gateways to enforce server-side authorization checks consistently and centrally
• Practical detection strategies using logs, API gateways, and behavioral analytics to spot enumeration and unauthorized access attempts
• A repeatable review methodology you can apply to any application—legacy or cloud-native—to uncover BOLA issues before attackers do

Our sponsor for this real training for free event is A10 Networks and Carlo Alpuerto will speak to using the attacker centric approach to addressing security against this type of attack.

Please join us for this real training for free session.