About the Author
This article was written by Ahmar Imam with over a decade of combined experience in threat intelligence, identity protection, and incident response. Ahmar is a founder of D3C Consulting, where his team monitors emerging attack campaigns daily and works directly with enterprise security teams and individual consumers to mitigate data breach risks.
Reviewed by: Senior Threat Intelligence Analyst | Certified Information Security Professional (CISSP) | Identity Management expert
Imagine logging into your bank’s app and just changing one number in the web address. Suddenly, you’re looking at someone else’s account balance. That’s not a far-fetched scenario; it’s exactly how Broken Object Level Authorization (BOLA) works. And it’s the number one API security risk on the planet.
In 2023 and beyond, APIs are the backbone of every app, platform, and digital service. But many of them have a critical flaw: they check who you are, but not what you’re allowed to see. That one oversight has cost companies billions of dollars and exposed millions of people’s private data.
This guide will walk you through everything you need to know in plain language. Whether you’re a developer, a security engineer, or a business leader trying to protect your company, this is your complete BOLA playbook.
#1
OWASP API Security Rank
57%
Orgs Breached via BOLA
$4.45M
Avg. Cost of API Data Breach
1. What Is Broken Object Level Authorization (BOLA)?
BOLA stands for Broken Object Level Authorization. It is also called IDOR, which stands for Insecure Direct Object Reference. Both terms describe the same core problem.
Here is the simple version: when your API sends or receives data, it uses an identifier, usually a number or code, to find the right record. For example:
GET /api/orders/10042 → Returns YOUR order details
GET /api/orders/10043 → Should be someone else’s order… but with BOLA, it returns their data too.
A properly secured API would check: ‘Is this user authorized to see order #10043?’ A BOLA-vulnerable API skips that check. It only verifies that the user is logged in, not that they have permission to access that specific object.
The OWASP (Open Web Application Security Project) listed BOLA as the #1 risk in its API Security Top 10. That is a big deal. OWASP is the gold standard for web security guidance. Being ranked #1 means this flaw is both extremely common and extremely dangerous.
2. BOLA vs. IDOR: Are They the Same Thing?
You will see both terms used in cybersecurity writing. Here is the difference, and why it matters for SEO and technical understanding.
Term | Full Name | Where It Came From | Scope |
IDOR | Insecure Direct Object Reference | OWASP Web App Top 10 (2013) | Web apps & APIs |
BOLA | Broken Object Level Authorization | OWASP API Security Top 10 (2019, 2023) | APIs specifically |
Verdict | Same root vulnerability | BOLA = modern API-focused term for IDOR | Both equally dangerous |
For this guide, BOLA and IDOR mean the same thing. If you are securing APIs, use the BOLA terminology, which is the current industry standard from OWASP.
3. Why Is BOLA So Dangerous? The Mass PII Exposure Problem
Most attacks require complex tools or great technical skill. BOLA does not. An attacker needs only a browser and curiosity. Here is why this vulnerability is especially destructive:
3.1 It Scales Automatically
Once an attacker finds one vulnerable endpoint, they can write a simple script that loops through thousands of IDs. In minutes, they can collect records for thousands of users, names, email addresses, phone numbers, financial data, health records, and more.
3.2 It Leaves Almost No Trace
Because the requests look like normal API traffic, valid tokens, proper formatting, security tools often miss them. There is no malware, no injection, no brute force. It is just someone making what looks like a legitimate request.
3.3 The Data Is Immediately Valuable
Exposed Personally Identifiable Information (PII) is sold on dark web markets within hours of a breach. Health records go for $250 each. Financial data sells for $5 to $110 per record. A single BOLA exploit can yield millions of records in one attack.
3.4 Regulatory Consequences Are Severe
Under GDPR, CCPA, HIPAA, and other regulations, exposing user PII through a preventable flaw can result in fines of up to 4% of annual global revenue, or $20 million, whichever is greater, under GDPR.
⚠ KEY STAT:
According to Salt Security’s 2023 State of API Security Report, 94% of security professionals experienced API security problems in the past year, and BOLA-type flaws were among the top causes.
4. Real-World BOLA Breaches: Uber, Trello, and Facebook
These are not theoretical risks. Some of the world’s most recognized companies have been hit by BOLA vulnerabilities. Here are three major case studies.
4.1 Uber, Driver & Rider PII Exposed
In 2016, a security researcher found that Uber’s driver partner API did not properly validate object-level access. By manipulating the numeric driver ID in an API request, the researcher could pull full profile details, names, phone numbers, license plate data, and location history for any driver on the platform.
Uber had millions of drivers. The potential scope of exposure was enormous. This same class of vulnerability contributed to Uber’s 2016 data breach, which exposed 57 million rider and driver records and resulted in a $148 million settlement with U.S. state attorneys general.
4.2 Trello, Private Board Data Leaked
In 2021, researchers discovered that Trello’s API allowed access to boards marked as private simply by knowing the board’s unique identifier. Because the authorization check was missing, anyone with the right URL structure could retrieve data from boards they had no access to.
For businesses using Trello to store internal project details, client information, or product roadmaps, this was a serious exposure. Trello responded quickly with a patch, but the incident highlighted how even productivity tools carry API-level authorization risks.
4.3 Facebook / Instagram, Account Data via API
Meta has faced multiple BOLA-style vulnerabilities across Facebook and Instagram. In one widely reported case, researchers found that the Instagram API returned private user data, including phone numbers and email addresses, when queried with a valid but unauthorized object reference. The vulnerability was reported through Meta’s bug bounty program, but it demonstrated that even trillion-dollar companies struggle with object-level authorization.
Company | Year | What Was Exposed | Outcome |
Uber | 2016 | 57M driver & rider records, PII | $148M settlement |
Trello | 2021 | Private board contents, business data | Emergency patch |
2019 | Phone numbers, emails via the Instagram API | Bug bounty payout | |
Peloton | 2021 | User profile data, workout history | Public disclosure |
T-Mobile | 2023 | 37M customer accounts via API | FTC investigation |
5. How BOLA Attacks Work: A Technical Walkthrough
Understanding the attack helps you understand the defense. Here is a step-by-step look at how a BOLA attack unfolds.
Step 1: Reconnaissance, Find the API Endpoints
Attackers use browser developer tools, Burp Suite, or publicly available API documentation to identify endpoints that return user-specific data. Common targets include:
- /api/users/{id}
- /api/accounts/{account_id}/statements
- /api/orders/{order_id}
- /api/documents/{doc_id}
- /api/healthcare/records/{patient_id}
Step 2: Probe the Object IDs
The attacker makes a legitimate request with their own ID, then changes the ID value. They may try sequential integers (10042, 10043, 10044), UUIDs if they can guess the format, or IDs referenced in other API responses.
Step 3: Confirm the Vulnerability
If the server returns another user’s data instead of an error or authorization denial, the endpoint is vulnerable. The attacker now has a repeatable method to extract data at scale.
Step 4: Automate the Extraction
Using tools like Python scripts, Burp Suite Intruder, or custom automation, the attacker loops through thousands of IDs, collecting and storing each response. A basic script can pull 10,000 records per hour.
Step 5: Monetize or Weaponize
The stolen data is used for identity theft, sold on dark web marketplaces, used for targeted phishing attacks, or held as leverage in ransomware negotiations.
DEVELOPER NOTE
Always test your own APIs before attackers do. Use automated BOLA scanners as part of your CI/CD pipeline. One hour of security testing can save millions in breach costs.
6. The Root Causes of BOLA Vulnerabilities
BOLA does not just happen by accident. There are specific development patterns and organizational failures that create it. Understanding the root causes helps you fix it at the source.
6.1 Authentication ≠ Authorization
This is the most common misunderstanding. Authentication answers: ‘Who are you?’ Authorization answers: ‘What are you allowed to do?’ Many developers implement strong authentication (JWT tokens, OAuth, MFA) but forget to implement object-level authorization on every endpoint.
6.2 Predictable Object IDs
Sequential integers (user_id=1001, 1002, 1003) are easy to guess. Even UUIDs can be discovered through API responses. Using non-guessable IDs reduces the attack surface, but does not eliminate BOLA; the authorization check must still exist.
6.3 Over-Permissive API Design
APIs that return more data than needed (‘over-fetching’) increase the damage from a BOLA exploit. If an endpoint returns a full user object when only the username is needed, a BOLA exploit exposes the entire object.
6.4 Missing Server-Side Validation
Client-side checks are useless for API security. The check must happen on the server, every single time, for every single request. A common mistake is checking ownership during UI rendering but not at the API layer.
6.5 Inherited Legacy Code
Many APIs are built on top of older systems that were never designed with authorization controls in mind. When endpoints are added quickly to meet business deadlines, security checks get skipped.
7. How to Detect BOLA in Your API
Finding BOLA vulnerabilities before attackers do is critical. Here are the most effective detection methods.
7.1 Manual Penetration Testing
A skilled penetration tester will systematically swap object IDs across all API endpoints, testing whether the server enforces authorization at the object level. This is the most thorough method but requires expertise.
7.2 Automated BOLA Scanners
Several tools are purpose-built for API security testing. Look for tools that support:
- Automated ID fuzzing across all discovered endpoints
- Authentication context switching (testing as User A accessing User B’s objects)
- GraphQL and REST API support
- Integration with CI/CD pipelines
7.3 API Traffic Analysis
Deploy API security gateways that analyze traffic patterns. Unusual patterns, like one user requesting thousands of different object IDs, are a strong indicator of a BOLA attack or active reconnaissance.
7.4 Runtime Application Self-Protection (RASP)
RASP tools can detect when an application is being manipulated in real time and block the request before data is returned. When implemented at the API gateway layer, RASP provides continuous BOLA protection.
8. How to Fix BOLA: A Step-by-Step Remediation Guide
Fixing BOLA requires changes at the code level, the architecture level, and the process level. Here is a comprehensive remediation plan.
Step 1: Implement Object-Level Authorization on Every Endpoint
For every API endpoint that returns or modifies data tied to a specific object (user, order, document, etc.), add a server-side check that confirms the requesting user owns or has explicit permission to access that object.
// BAD: Only checks if user is authenticated
app.get(‘/api/orders/:id’, authenticate, (req, res) => {
return db.getOrder(req.params.id); // No ownership check!
});
// GOOD: Checks authentication AND ownership
app.get(‘/api/orders/:id’, authenticate, async (req, res) => {
const order = await db.getOrder(req.params.id);
if (order.userId !== req.user.id) {
return res.status(403).json({ error: ‘Forbidden’ });
}
return res.json(order);
});
Step 2: Use Non-Predictable Object IDs
Replace sequential integers with UUIDs (version 4 or above) or other non-guessable identifiers. While this is not a substitute for proper authorization checks, it significantly raises the effort required for an attacker.
Step 3: Apply the Principle of Least Privilege
Design your authorization model so that users can access only the minimum data they need. Scope API tokens to specific resources and actions. An e-commerce customer token should not be able to read other customers’ profiles.
Step 4: Centralize Authorization Logic
Avoid writing authorization checks in each controller. Instead, use a centralized authorization layer or middleware, ideally powered by a policy engine like Open Policy Agent (OPA) or a similar access control framework.
Step 5: Return Generic Error Responses
When a user tries to access an object they do not have permission for, return a 403 Forbidden or 404 Not Found status, not a message like ‘You do not own this order.’ Generic errors prevent attackers from learning about resource existence through error messages.
Step 6: Add BOLA Tests to Your CI/CD Pipeline
Treat authorization testing like unit testing. Write automated tests that verify a user cannot access another user’s resources. Run these tests on every deployment.
Step 7: Conduct Regular API Security Audits
Schedule penetration tests and code reviews specifically focused on authorization logic at least twice a year. APIs evolve fast. New endpoints get added, and old security checks get missed.
Step 8: Train Your Development Team
Most BOLA vulnerabilities are not introduced by malice; they come from gaps in developer knowledge. Regular security training focused on API authorization concepts can eliminate the most common mistakes before they reach production.
Fix | Difficulty | Impact | Priority |
Add object-level authz checks | Medium | Critical | Immediate |
Use UUIDs instead of int IDs | Low | High | High |
Centralize authorization logic | High | Critical | Immediate |
Add BOLA tests to CI/CD | Medium | High | High |
API traffic anomaly monitoring | Medium | High | High |
Developer security training | Low | Medium | Medium |
Regular penetration testing | High | Critical | Immediate |
9. BOLA in the OWASP API Security Top 10 (2023 Edition)
OWASP updates its API Security Top 10 list to reflect the current threat landscape. BOLA has held the #1 spot since the list’s creation in 2019, and it retained that position in the 2023 update.
Here is where BOLA sits in context with other major API risks:
Rank | OWASP API Risk | Brief Description |
API1:2023 �� | Broken Object Level Authorization (BOLA) | Users access other users’ objects; this guide’s focus |
API2:2023 | Broken Authentication | Weak auth mechanisms, exposed tokens |
API3:2023 | Broken Object Property Level Auth | Over-exposure of object properties |
API4:2023 | Unrestricted Resource Consumption | No rate limiting, DoS vulnerability |
API5:2023 | Broken Function Level Authorization | Users access admin functions |
API6:2023 | Unrestricted Access to Sensitive Flows | Automation of sensitive workflows |
API7:2023 | Server Side Request Forgery (SSRF) | API calls to internal resources |
API8:2023 | Security Misconfiguration | Default configs, open debug endpoints |
API9:2023 | Improper Inventory Management | Shadow APIs, outdated versions |
API10:2023 | Unsafe Consumption of APIs | Trusting third-party APIs blindly |
Understanding the full OWASP list helps security teams prioritize their remediation roadmap. Fixing BOLA alone addresses a massive portion of API risk, but a complete API security program covers all ten categories.
10. BOLA and Regulatory Compliance
A BOLA breach is not just a technical problem; it is a legal and financial problem. Here is how object-level authorization failures intersect with major regulations.
GDPR (Europe)
Under Article 32 of GDPR, organizations must implement appropriate technical measures to ensure data security. Failing to implement authorization controls that prevent unauthorized access to personal data is a direct GDPR violation. Fines can reach 20 million euros or 4% of global annual revenue, whichever is higher.
CCPA (California)
California’s Consumer Privacy Act gives residents the right to know how their data is used and the right to sue if their data is exposed due to inadequate security. A BOLA breach affecting California residents opens companies to class-action liability.
HIPAA (Healthcare)
If your API handles Protected Health Information (PHI) and BOLA allows unauthorized access to patient records, that is a HIPAA breach. Penalties range from $100 to $50,000 per violation, with an annual cap of $1.9 million per violation category.
PCI DSS (Payments)
APIs that handle payment card data must meet PCI DSS requirements. Requirement 7 mandates restricting access to system components based on business need. BOLA is a direct violation of this requirement.
11. Tools and Technologies for BOLA Prevention
No single tool eliminates BOLA risk. The most effective approach is a combination of tools across the development lifecycle.
Development Phase
- OWASP ZAP, an open-source API security scanner
- Burp Suite Professional, Industry-standard penetration testing
- Postman, API testing with security test collections
- 42Crunch, OpenAPI security analysis
CI/CD Integration
- StackHawk, DAST testing in CI/CD pipelines
- Veracode, Static and dynamic analysis
- Checkmarx, SAST with API security rules
Runtime Protection
- Salt Security, AI-powered API threat detection
- Noname Security, API security posture management
- Traceable AI, API observability, and threat detection
- AWS API Gateway, Built-in authorization policies
- Kong, API gateway with plugin ecosystem
Authorization Frameworks
- Open Policy Agent (OPA), Policy-based access control
- Casbin, an authorization library for multiple languages
- Auth0 Fine-Grained Authorization, RBAC/ABAC for APIs
PRO TIP
Start with OWASP ZAP (free) and Burp Suite Community Edition for immediate BOLA detection. Then invest in runtime monitoring tools once your codebase is audited. Do not wait for a breach to act.
12. Building a BOLA-Resilient API Security Program
Fixing individual vulnerabilities is reactive. Building a program is proactive. Here is what a mature API security program looks like.
12.1 Establish an API Inventory
You cannot secure what you cannot see. Maintain a complete, up-to-date inventory of all APIs, public, private, and internal. Include version numbers, owners, and data sensitivity classifications. Shadow APIs (undocumented or forgotten endpoints) are a top BOLA attack surface.
12.2 Define an Authorization Policy
Document exactly who should have access to what. Use a formal model like Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC). This document becomes the blueprint for your code-level authorization logic.
12.3 Shift Security Left
Security should start at the design stage, not after deployment. Include authorization requirements in user stories and API design documents. Review authorization logic during code reviews before merging.
12.4 Implement Continuous Monitoring
Deploy tools that monitor API traffic 24/7 for signs of BOLA exploitation, unusual ID enumeration patterns, high volumes of requests from a single user, or access to objects outside a user’s normal scope.
12.5 Create an Incident Response Plan
Know what you will do when, not if, a BOLA vulnerability is discovered or exploited. Have a playbook that covers: containment, affected user notification, regulatory reporting, and post-incident remediation.
Key Takeaways
BOLA is not a complex attack. It is a simple check,’ Can this user access this object?’, that millions of APIs skip. That one missing check has caused some of the largest data breaches in history, exposed the personal information of hundreds of millions of people, and cost companies billions of dollars in penalties and settlements.
The good news: BOLA is entirely preventable. Every point in this guide, from understanding the attack to implementing the fix, is actionable today. Whether you are a solo developer, a security engineer, or a CISO, the steps are clear.
Start with an API inventory. Add object-level authorization checks. Test your APIs the way an attacker would. And build a culture where security is part of every API design conversation, not an afterthought.
The attackers already know about BOLA. The only question is whether your defenses know about it, too.
