API Security
Penetration Testing
Authentication
OWASP Top 10
ISO 27001
REST APIs
GraphQL
Security Testing
Burp Suite
OWASP ZAP
API Security
Penetration Testing
Authentication
OWASP Top 10
ISO 27001
REST APIs
GraphQL
Security Testing
Burp Suite
OWASP ZAP
← Back to Blog

What is BOLA? Broken Object Level Authorization Explained in Simple Terms

Imagine you're at a bank. You have your own safety deposit box, and you have the key. The bank should only let you open your box, not someone else's. But what if the bank didn't check which box belongs to you? What if you could use your key to open any box you wanted?

That's essentially what Broken Object Level Authorization (BOLA) is in the world of APIs.

#1
OWASP API Top 10
94%
Of APIs have this issue
Critical
Severity level

The Simple Explanation

What Does "Object Level" Mean?

In API terms, an "object" is a specific piece of data: a user profile, an order, a document, a message. Each object has an ID (like a box number).

When you make an API request, you're asking for a specific object. For example:

API Request Examples

  • GET /api/users/123 — "Give me user profile #123"
  • GET /api/orders/456 — "Give me order #456"
  • GET /api/documents/789 — "Give me document #789"

The Problem

With BOLA, the API checks if you're logged in (authentication), but it doesn't check if you're allowed to access that specific object (authorization).

What Happens with BOLA

  • You log in successfully — the API knows who you are
  • You request your own profile — you get it (this works fine)
  • You request someone else's profile — you still get it (this shouldn't happen!)

The API says: "You're logged in, so here's whatever you asked for." It doesn't ask: "Wait, is this actually yours?"

A Real-World Example

Let's say you're using a social media app:

  1. You log in as user "alice"
  2. You can see your own profile at /api/profile/alice
  3. You change the URL to /api/profile/bob
  4. Instead of getting an error, you see Bob's private profile

This is BOLA. The API authenticated you (you're logged in), but it didn't authorize you to access Bob's data.

Why Is This Dangerous?

Personal Information

Access other users' personal information, private messages, documents, or files

Payment Details

See payment details, order history, and financial information

Data Modification

Modify or delete other users' data if the API also has write vulnerabilities

Easy Exploitation

All of this can happen just by changing a number in a URL or API request

How to Fix It

The solution is simple in concept but requires proper implementation:

Best Practices

  • Check ownership — Before returning any object, verify that the logged-in user actually owns or has permission to access that specific object
  • Don't trust the client — Never rely on the client to tell you what they're allowed to see
  • Validate on the server — Always perform authorization checks on the server side

Instead of:

if (user.isLoggedIn()) {
    return getUserProfile(userId);
}

Do this:

if (user.isLoggedIn() && user.id === userId) {
    return getUserProfile(userId);
} else {
    return error("Access denied");
}

BOLA in the OWASP API Top 10

BOLA is ranked as API1 in the OWASP API Security Top 10, meaning it's considered one of the most critical and common vulnerabilities in APIs. It's not just a theoretical issue — it's found in real applications all the time.

Summary

BOLA happens when an API checks "Are you logged in?" but forgets to check "Are you allowed to access this specific thing?"

It's like a bank that checks your ID but doesn't verify which safety deposit box is yours. Simple to understand, dangerous in practice, and unfortunately very common.

Want to dive deeper? Read our article Broken Object Level Authorization (BOLA) in APIs — How It Appears in Real Systems to understand how BOLA manifests in practice and why it's often missed during development.