Broken Object Level Authorization (BOLA) lets attackers access data or actions belonging to other users by changing object identifiers in API requests. It ranks first on the OWASP API Security Top 10. This article explains what BOLA is, why it persists, how Dynamic Application Security Testing (DAST) can detect it with multi-user testing and ID manipulation, and what to combine with automation for stronger coverage.
What is Broken Object Level Authorization (BOLA)?
Broken Object Level Authorization (BOLA) occurs when an API fails to verify that the authenticated user is allowed to access the specific object referenced in a request. It is closely related to Insecure Direct Object Reference (IDOR)—changing an ID in a URL or body to reach another user's resource—but BOLA emphasizes the missing authorization check, not just predictable identifiers. BOLA is API1 in the OWASP API Security Top 10.
In practice, an attacker modifies a parameter that refers to an object—a user ID, order ID, invoice UUID, or file path—to read or change data they should not see. The flaw is trusting that possession of a valid token or knowing an ID implies permission, without a server-side check that ties the object to the caller.
Example: an endpoint GET /api/users/{id} returns a profile when user 123 is authenticated. If changing id to 456 returns another user's data with HTTP 200, that is BOLA. Impact ranges from data exposure to privilege escalation when admin or billing objects are affected.
Why BOLA is a persistent threat
BOLA is easy to introduce and hard to catch with code review alone:
- Large API surface. Many endpoints accept object IDs; one missing check on a secondary route is enough.
- Inconsistent authorization. Teams often implement access control differently per service or handler.
- Runtime-only behavior. Whether user A can read object B depends on live data and roles—you need tests that exercise the running API.
- Subtle success signals. Unauthorized access may return 200 with partial data, not an obvious 403, so manual spot checks miss it.
How DAST helps uncover BOLA
Dynamic Application Security Testing (DAST) probes a running API from the outside, like an attacker. It does not replace design review or static analysis, but it is well suited to authorization flaws that only appear when requests are sent with real tokens and swapped object IDs. For API coverage patterns, see API security testing with DAST.
- Multiple auth profiles. Configure sessions for different users or roles so the scanner can request the same endpoint as user A while substituting IDs that belong to user B.
- Spec-driven endpoints. OpenAPI or GraphQL schemas list paths and parameters to mutate, reducing the chance that ID-bearing routes are skipped.
- ID manipulation. Sequential, random, and cross-account identifier swaps in paths, query strings, and JSON bodies surface missing object-level checks.
- Evidence in reports. Findings tie to the endpoint, parameter, request, and response so developers can reproduce and fix quickly.
Rule-based DAST is strongest for straightforward IDOR-style BOLA. Chains that depend on obscure business rules may still need manual tests or broader exploration—see what DAST covers without a pentest and AI-powered security scanning for gaps automation alone can miss.
Practical strategies for DAST-based BOLA detection
- Keep API specs current. Accurate OpenAPI or GraphQL definitions give the scanner a complete map of ID parameters.
- Use realistic test users. At minimum, two non-admin accounts plus an admin (if in scope) to test horizontal and vertical access mistakes.
- Prioritize sensitive objects. Focus on endpoints for profiles, orders, documents, admin actions, and any route with UUIDs or numeric IDs in the path.
- Fuzz identifiers deliberately. Try IDs from another session, out-of-range values, and type confusion—not only the authenticated user's own IDs.
- Automate in CI/CD. Run scans on staging after deploy so new endpoints are checked before production. See DAST in CI/CD for pipeline patterns.
- Triage carefully. Treat unexpected 200 responses with another user's data as high priority; confirm false positives by replaying requests manually.
Preventing BOLA in development
Detection and prevention work together. In code and design:
- Authorize every object access. After authentication, verify the caller may act on this record—never assume the client only sends IDs it owns.
- Centralize policy. Shared middleware or policy engines reduce one-off checks that drift between teams.
- Validate inputs. Enforce expected types and formats for IDs; reject malformed references early.
- Least privilege. Default roles should not reach objects outside their tenant or scope.
Pair these practices with recurring DAST. If you are new to the approach, start with what is DAST.
Conclusion
BOLA remains one of the most common API failures because a single missing check on one endpoint is enough to leak customer data. DAST adds repeatable, multi-user testing that swaps object IDs against a live deployment—exactly the class of mistake code review often misses. Combine automated scans with consistent server-side authorization, accurate API specs, and deeper review where business logic is complex.
Visit scryn.cloud to run DAST against your APIs with authenticated profiles and actionable reports.