BOLA and IDOR: why your API exposes other customers' data
> TL;DR: Understanding Broken Object Level Authorization and Insecure Direct Object Reference flaws, exploitation techniques, and protections.
BOLA and IDOR, are they the same thing?
Nearly. IDOR (Insecure Direct Object Reference) is the legacy term. BOLA (Broken Object Level Authorization) is the term used by the OWASP API Security Top 10 since 2019. The concept is identical: an authenticated user accesses another user's resources by manipulating the resource identifier in the request.
Why it's so common
Web frameworks make it easy to create CRUD routes. A developer creates GET /api/documents/:id and the controller fetches the document by ID. But verifying that the logged-in user is authorized to view that document is a manual step. No framework adds it automatically. You have to explicitly write if (document.userId !== currentUser.id) return 403.
Aggravating factor: sequential identifiers. If IDs are 1, 2, 3, 4..., the attacker can enumerate them all. UUIDs reduce the enumeration risk but don't replace authorization checks.
Exploitation techniques
Direct enumeration
The attacker iterates through a range of IDs: GET /api/users/1, GET /api/users/2, and so on. With an automated script, thousands of profiles are extracted in minutes.
Parameter manipulation
Changing user_id in the body of a POST or PATCH request. If POST /api/transfer accepts {"from_account": "attacker", "to_account": "victim", "amount": 1000} without verifying the caller owns the source account, that's a critical BOLA.
GraphQL and nested queries
In GraphQL, an attacker can navigate relationships: query { user(id: 42) { documents { content } } }. If the User type resolver doesn't check authorization, any user's documents are accessible.
Via files and media
Download URLs with predictable IDs: /api/files/invoice_1042.pdf. The attacker changes the invoice number to access other customers' documents.
Defenses
Real impact
BOLA enables mass exfiltration of personal data. Under GDPR, that's a data breach requiring notification to the supervisory authority within 72 hours. At CleanIssue, we identify BOLA in roughly 40% of the APIs we audit. Request your audit call.
Key Takeaways
Building HR, payroll, or recruiting software? CleanIssue performs security audits for HR SaaS in real-world conditions, no source code access needed. For a first read of your exposure, start with an external review of your application.
Related articles
Three adjacent analyses to keep exploring the same attack surface.
API and webhook vulnerabilities: the 2026 guide to the mistakes that really expose data
Reference guide to the API and webhook mistakes that create real exposure: BOLA, mass assignment, sensitive business flows, HMAC signatures, overly verbose docs, and over-trusting callbacks.
User enumeration: how your API reveals who your customers are
Differentiated error messages, sequential IDs, endpoints without rate limiting: your API may allow listing your customers and their employees. Why it matters for HR SaaS, and how to fix it.
OWASP API Top 10: the 10 API flaws to know in 2026
Analysis of the 10 most critical API vulnerabilities per the OWASP API Security Top 10 2023, with practical examples for each category.
Sources
Editorial analysis based on official vendor, project, and regulator documentation.
Related services
If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.