What BOLA Really Means in APIs (And Why UI Authorization Is Not Security)

If you work with APIs—especially modern REST or mobile APIs—you’ve probably heard the term BOLA.

It stands for Broken Object Level Authorization, and it’s currently the #1 vulnerability in the OWASP API Top 10.

Yet, many developers still misunderstand it.

This post explains:

• What BOLA actually means
• Why UI authorization is not real security
• How this vulnerability appears in real-world APIs
• What developers and pentesters should look for

Authentication ≠ Authorization

Let’s start with a simple truth:

Just because a user is logged in does not mean they should access everything.

Most APIs do authentication correctly:

• JWTs
• OAuth tokens
• Session cookies

But authorization at the object level is where things often break.

What Is BOLA?

Broken Object Level Authorization happens when an API:

• Accepts a valid object identifier (ID, UUID, hash)
• But does not verify whether the authenticated user is allowed to access that specific object

In simple terms:

The API trusts the object ID more than the user.

UI Authorization vs API Authorization

This is where most confusion comes from.

UI Authorization (Cosmetic Security)

UI authorization usually looks like:

• Buttons hidden for non-admin users
• Pages not linked in navigation
• Disabled UI elements

Example:

• The “Download Invoice” button is hidden unless you own the invoice

Problem:
The backend API may still allow:

GET /api/invoices/12345

…for any authenticated user.

The UI hides features.
The API still serves data.

API Authorization (Real Security)

Proper API authorization means:

• Every request checks ownership or permission
• Every object ID is validated against the user context
• The backend decides, not the frontend

Example logic:

• “Does this invoice belong to the authenticated user?”
• If not → return 403 Forbidden

Real-World BOLA Example

Imagine a SaaS dashboard.

UI behavior

• You can only see your own invoices
• Other invoices are not shown anywhere

API request

GET /api/invoices/78421
Authorization: Bearer <your_token>

You change the ID:

GET /api/invoices/78422

If the API returns another user’s invoice:
That’s BOLA

No UI bug.
No broken login.
Just broken object authorization.

Why APIs Are Especially Vulnerable

APIs are:

• Directly callable (curl, Postman, Burp, mobile apps)
• Often reused across web, mobile, and integrations
• Designed for speed and flexibility, not safety

Common developer mistakes:

• Trusting IDs sent by the client
• Checking authorization only at login
• Assuming UUIDs are “secure”
• Relying on frontend logic

Common BOLA Scenarios

BOLA appears in many forms:

• Viewing another user’s profile
• Downloading someone else’s invoice
• Accessing another organization’s reports
• Seeing internal flags like is_admin, risk_score
• Accessing deleted or archived objects

Most of these bugs expose PII, financial data, or organization-level secrets.

Key Takeaway

UI authorization is not security.
API authorization must be enforced for every object, every time.

If your API accepts an object ID:

• Validate ownership
• Validate permissions
• Never trust the client

For Developers

Ask yourself:

• “Am I checking who owns this object?”
• “Am I validating access on every endpoint?”
• “Would this endpoint still be safe without a UI?”

For Security Testers

When testing APIs:

• Always modify object IDs
• Compare responses field by field
• Test the same object via different endpoints
• Don’t trust UUIDs or hidden UI features

Final Thought

Most API breaches don’t happen because of weak passwords.

They happen because the system trusts users with data they should never see.

That’s BOLA.