Why WAFs Fail Against BOLA and IDOR Attacks

Authorization failures are now the dominant cause of API security incidents, even in environments where web application firewalls are correctly deployed and actively managed. Among these failures, Broken Object Level Authorization and Insecure Direct Object References consistently appear as the most exploited weaknesses in production APIs.

This is not a fringe observation. Industry research points to a persistent gap between how APIs are protected and how they are actually abused. Gartner has repeatedly highlighted authorization as the most common control failure in API-related breaches, noting that these incidents typically occur without triggering traditional perimeter defenses. Requests are authenticated, endpoints are valid, and traffic patterns often remain within expected thresholds.

The prevalence of these failures is closely tied to how APIs are built and consumed. According to the State of the API reports published by Postman, APIs now serve as the primary interface for applications, partners, and automated systems. As organizations adopt API-first architectures, they increasingly expose business objects and identifiers directly through API endpoints. This design choice improves flexibility and integration, but it also shifts risk toward authorization logic that must be enforced consistently across every request.

The impact of authorization failures is reflected in breach outcomes as well. IBM’s annual Cost of a Data Breach studies continue to show that incidents involving misuse of valid credentials and unauthorized data access are among the most expensive to detect and remediate. These breaches rarely involve exploit payloads or malformed traffic. They involve legitimate users or compromised identities accessing data they should not be able to see.

What makes BOLA and IDOR particularly difficult to address is that they do not look like attacks at the network or protocol level. They are the result of missing or inconsistent authorization checks applied to otherwise valid requests. From the perspective of a WAF, the traffic appears normal. From the perspective of the application, the requests are syntactically correct. The failure exists in the relationship between identity, object, and context.

What Are BOLA and IDOR Attacks

Broken Object Level Authorization (BOLA) and Insecure Direct Object References (IDOR) are closely related authorization failures that occur when an API does not properly enforce access control on the objects it exposes.

Both attacks exploit the same underlying weakness: the system accepts user-supplied object identifiers without consistently verifying whether the requesting identity is authorized to access the referenced object.

Broken Object Level Authorization (BOLA)

BOLA occurs when an API allows a user to access or manipulate objects that belong to other users or entities because object-level authorization checks are missing or incomplete.

In a typical API design, endpoints accept identifiers such as user IDs, account numbers, order IDs, or resource keys as request parameters. If the API validates that the identifier exists but does not verify ownership or scope, an authenticated user can access objects outside their authorization boundary simply by changing the identifier value.

BOLA is ranked as a top risk in the OWASP API Security Top 10 because it leads directly to unauthorized data exposure and modification. It does not require advanced techniques. It requires only the ability to send valid requests with altered identifiers.

Insecure Direct Object References (IDOR)

IDOR is a specific manifestation of the same problem. It occurs when an application exposes direct references to internal objects and relies on those references as the sole control mechanism.

In an API context, IDOR typically appears when:

• Object identifiers are predictable or enumerable
• Authorization checks are applied inconsistently across endpoints
• Access control is enforced at the UI layer but not at the API layer

An API may correctly restrict access in one endpoint but fail to apply the same checks in another, creating uneven enforcement across the system.

Relationship between BOLA and IDOR

BOLA and IDOR are often discussed separately, but in practice they represent the same class of failure viewed at different levels.

IDOR describes how the object reference is exposed.

BOLA describes the absence of proper authorization enforcement on that reference.

From a defensive perspective, the distinction is less important than the shared root cause. In both cases, the API accepts a request that is syntactically valid, authenticated, and well-formed, but does not verify that the requesting identity should be allowed to access the referenced object.

Why this matters for API security

These attacks do not rely on malformed requests, injection payloads, or protocol abuse. They operate entirely within the expected usage of the API. As a result, they bypass controls that focus on request structure, signatures, or rate limits.

Understanding BOLA and IDOR as authorization failures rather than input validation issues is essential to understanding why traditional perimeter defenses struggle to detect them.

Why BOLA and IDOR Are API-Native Risks

Broken Object Level Authorization and Insecure Direct Object References are not edge cases caused by isolated coding mistakes. They arise from how APIs are designed to expose data and functionality.

APIs expose objects directly

APIs operate on business objects rather than pages. Endpoints are designed to retrieve, update, or delete specific resources, and those resources are identified explicitly in each request.

Common examples include account IDs, order numbers, document references, and relationship keys passed as path parameters or request fields. These identifiers are typically controlled by the client, not derived implicitly by the system.

This design improves flexibility and reuse, but it also places authorization enforcement squarely on the API layer.

Authorization logic is distributed across services

In modern architectures, authorization checks are rarely centralized. Different services enforce access control independently, often based on local assumptions about identity, scope, or upstream validation.

As APIs evolve, this leads to uneven enforcement. One endpoint may correctly validate object ownership, while another assumes that the caller has already been authorized. These gaps are difficult to detect through testing alone, especially in large and rapidly changing systems.

APIs are consumed by many clients

APIs are no longer used by a single frontend application. They are accessed by web clients, mobile apps, partner integrations, internal services, and automated systems.

Each client exercises different code paths and usage patterns. Authorization logic that appears correct for one client may fail when exercised in a different context. Less frequently used endpoints and edge-case workflows are particularly susceptible to inconsistent checks.

Statelessness increases enforcement risk

APIs are designed to be stateless. Every request must carry the information required to authorize and process it, including identity and object references.

This stateless model removes implicit context. If authorization checks are not applied explicitly and consistently on every request, the API has no memory of prior validation. As a result, missing or partial checks immediately translate into unauthorized access.

Why this matters for security controls

These characteristics make BOLA and IDOR API-native risks. They emerge from normal, well-formed requests that follow documented API usage patterns.

There is no malformed input to inspect and no protocol violation to flag. The failure exists in the relationship between identity and object, not in the request itself.

This is why BOLA and IDOR attacks persist even in environments with mature perimeter defenses. They are authorization failures embedded in system behavior, not anomalies at the network or payload level.

How Traditional WAFs Evaluate Requests

Traditional WAFs are designed to evaluate individual HTTP requests as they enter an application. Their inspection model is optimized for identifying malicious input patterns rather than understanding how requests relate to application data or user intent.

Request-centric inspection

At the core of a traditional WAF is request-by-request analysis. Each incoming request is evaluated independently based on its headers, parameters, and payload.

The WAF does not maintain awareness of:

• Prior requests from the same identity
• Relationships between different API calls
• How an object referenced in one request relates to earlier activity

This stateless inspection model works well for detecting attacks that are visible within a single request. It is poorly suited for risks that emerge across multiple requests over time.

Signature and pattern-based detection

Traditional WAFs rely heavily on predefined rules and signatures derived from known web application attack techniques.

These rules are effective at identifying:

• Injection attempts
• Malformed input
• Protocol violations
• Known exploit patterns

However, BOLA and IDOR attacks do not rely on malformed input or suspicious payloads. They use valid identifiers, correct HTTP methods, and authenticated sessions. As a result, they do not trigger signature-based detection.

Limited understanding of application context

A traditional WAF does not understand application semantics. It does not know what a specific identifier represents, who owns the referenced object, or whether access should be permitted for a given identity.

From the WAF’s perspective, a request that retrieves one object is indistinguishable from a request that retrieves another, as long as both requests are syntactically correct and authorized at the transport level.

Authentication without authorization awareness

While many WAFs can detect the presence of authentication artifacts such as cookies or tokens, they do not reason about authorization.

They do not evaluate:

• Whether a user is allowed to access a specific object
• Whether an identifier falls within an authorized scope
• Whether access patterns are consistent with expected behavior

If authentication succeeds and the request conforms to expected structure, the request is typically allowed.

Why WAFs Cannot Detect BOLA and IDOR Attacks

The inability of traditional WAFs to detect BOLA and IDOR attacks is not a tooling gap. It is a consequence of what these controls are designed to see and what they are not.

No awareness of object ownership

BOLA and IDOR attacks depend on violating object ownership or access scope. Detecting them requires knowing which objects belong to which identities.

Traditional WAFs do not maintain this knowledge. They see identifiers as strings, not as references to protected resources. A request for one object is indistinguishable from a request for another if both are syntactically valid.

Without understanding ownership, the WAF cannot determine whether access should be allowed.

No modeling of identity to object relationships

Authorization is relational. It depends on how identities relate to objects, accounts, tenants, or roles.

Traditional WAFs do not model these relationships. They do not track which identities normally access which objects, nor do they maintain baselines of expected access scope.

As a result, an authenticated user accessing an unfamiliar or unauthorized object does not appear anomalous at the WAF layer.

No historical or behavioral context

BOLA and IDOR attacks often emerge across multiple requests.

An attacker may:

• Access one unauthorized object per request
• Spread access across sessions
• Remain within documented rate limits

Viewed in isolation, each request appears legitimate. Detecting abuse requires correlating activity across time and across requests.

Traditional WAFs evaluate requests independently. They do not correlate object access patterns or track cumulative behavior in a way that would expose this form of abuse.

Authorization logic exists beyond the edge

In modern systems, authorization decisions are typically enforced within application or service logic. They may depend on database lookups, policy engines, or contextual checks that occur after the request has passed the perimeter.

Traditional WAFs do not have access to this internal decision-making process. They cannot see whether authorization checks were applied correctly or whether they were bypassed altogether.

Once a request is allowed through the edge, the WAF’s role ends.

Why valid requests defeat perimeter inspection

BOLA and IDOR attacks use valid requests, valid tokens, and valid endpoints. There is no malformed input to inspect and no protocol violation to flag.

From the perspective of a traditional WAF, these requests meet all acceptance criteria. The control functions correctly, but the risk exists outside its field of view.

This is why environments can experience authorization-driven breaches while WAF dashboards remain quiet. The failure is not in blocking malicious traffic. It is in the absence of visibility into how access decisions are actually enforced.

Why API WAFs Improve Coverage but Still Fall Short

API WAFs address several limitations of traditional WAFs by introducing awareness of API structure and identity. They represent a meaningful improvement for API security. At the same time, they do not resolve the core challenge posed by BOLA and IDOR attacks.

Improved understanding of API structure

API WAFs are designed to understand that APIs are structured interfaces. They parse JSON payloads, recognize endpoints and methods, and can validate requests against expected schemas.

This allows API WAFs to:

• Reject requests with unexpected fields
• Enforce basic constraints on request structure
• Reduce false positives caused by generic string matching

These capabilities improve security posture at the API boundary and eliminate entire classes of malformed or abusive requests.

Better handling of API identities

Unlike traditional WAFs, API WAFs are built with token-based systems in mind. They can recognize API keys, OAuth tokens, and service identities and apply controls at that level.

This enables:

• Identity-aware rate limiting
• Differentiation between clients using the same endpoint
• More precise enforcement than IP-based controls

For many API misuse scenarios, this is a significant step forward.

Where the limitation of API WAF’s remain

Despite these improvements, API WAFs remain focused on request validity rather than authorization correctness.

Schema validation answers the question of whether a request is well-formed. It does not answer whether the requester is entitled to access the referenced object. An API WAF can confirm that an accountId field exists and is correctly typed, but it cannot determine whether that account belongs to the caller.

Similarly, identity awareness at the boundary does not translate into object-level authorization insight. API WAFs do not typically maintain mappings between identities and the full set of objects they are permitted to access. Without this context, they cannot distinguish legitimate access from unauthorized enumeration.

Contracts cannot encode authorization logic

API specifications describe structure and behavior, not dynamic access rules. Ownership, role-based access, and tenant isolation often depend on runtime state and business logic that cannot be fully expressed in an API contract.

As a result, even a perfectly enforced API schema can coexist with authorization flaws. Requests may comply with every documented rule while still accessing data they should not.

Edge visibility still defines detection limits

Like traditional WAFs, API WAFs operate at the boundary. They evaluate requests as they enter the system and do not observe how access decisions are enforced internally.

They cannot see:

• Which objects are returned by downstream services
• Whether authorization checks were applied correctly
• How access patterns evolve across multiple requests

For BOLA and IDOR attacks, this limitation is decisive. The abuse occurs within the bounds of valid API usage and only becomes visible when behavior is analyzed over time.

Where BOLA and IDOR Attacks Actually Occur in Practice

In production environments, BOLA and IDOR attacks rarely present as obvious spikes or anomalies. They unfold within normal-looking API usage patterns and often persist unnoticed for extended periods.

Authenticated users accessing unauthorized objects

Most BOLA and IDOR incidents occur after authentication has already succeeded. The attacker may be a legitimate user, a compromised account, or a partner integration with valid credentials.

Requests target legitimate endpoints and supply valid identifiers. The only difference is that the identifiers reference objects outside the caller’s authorized scope. Without object-level enforcement, these requests are processed normally.

Low-volume, incremental access patterns

Authorization abuse is often incremental rather than aggressive. Attackers may access a small number of unauthorized objects per session or per time window.

This approach avoids:

• Triggering rate limits
• Generating unusual traffic volumes
• Standing out from normal usage patterns
• Viewed request by request, the activity appears benign.

Enumeration across sessions and identities

In some cases, attackers distribute access attempts across multiple sessions or identities. This spreads activity even further below detection thresholds.

An individual identity may access only a handful of unauthorized objects. The full extent of the breach only becomes apparent when access patterns are correlated across identities and time.

Exploitation of uneven enforcement

Authorization checks are not always applied uniformly across an API surface. Some endpoints enforce ownership correctly, while others rely on upstream validation or shared assumptions.

Attackers identify and exploit these inconsistencies by targeting endpoints that expose the same objects but apply weaker checks. Because the endpoints are valid and documented, their use does not raise immediate alarms.

Delayed discovery through secondary signals

BOLA and IDOR attacks are often discovered indirectly.

Common discovery paths include:

• Customer reports of data exposure
• Audit findings
• Data reconciliation issues
• Unexpected downstream system behavior

By the time these signals emerge, the original access activity has already passed through accepted API paths without triggering edge controls.

Why Runtime Visibility Is Required to Detect Authorization Abuse

Detecting BOLA and IDOR attacks requires insight into how APIs are used over time, not just how individual requests are formed. This level of understanding is not available at the perimeter or API boundary alone.

Authorization abuse is pattern-based

BOLA and IDOR attacks do not rely on anomalous payloads or protocol violations. They rely on repeated access to objects that fall outside an identity’s authorized scope.

The signal of abuse emerges only when access patterns are analyzed across:

• Multiple requests
• Multiple sessions
• Extended time windows
• Different API endpoints referencing the same objects

Without correlating these dimensions, each request appears legitimate.

Identity to object correlation is essential

Effective detection depends on understanding which objects an identity normally accesses and how that access changes over time.

Runtime visibility makes it possible to:

• Associate identities with the objects they retrieve or modify
• Establish baselines for normal access scope
• Identify deviations that indicate unauthorized access

This correlation cannot be inferred from request structure alone. It requires observing real production behavior.

Context exists beyond the API boundary

Once a request passes edge enforcement, it interacts with internal services, databases, and downstream APIs. Authorization decisions may be applied inconsistently or bypassed entirely at these layers.

Runtime visibility allows security teams to observe:

• Whether authorization checks are applied consistently
• Which services return sensitive data
• How data flows after an API call is accepted

This context is necessary to distinguish legitimate access from silent data exposure.

Time-based analysis exposes low-and-slow abuse

Many authorization failures are intentionally subtle. Access is spread across time to avoid triggering alerts.

Runtime analysis enables detection of:

• Gradual expansion of accessed objects
• Repeated access to adjacent or related records
• Cumulative exposure that exceeds expected behavior

These patterns are invisible when requests are evaluated in isolation.

Why perimeter controls cannot fill this gap

Neither traditional WAFs nor API WAFs are designed to maintain long-term behavioral context. Their role ends once a request is allowed or blocked.

Runtime visibility complements these controls by focusing on what happens after access is granted. It shifts detection from static rules to observation of real system behavior.

How Enterprises Should Defend Against BOLA and IDOR

Defending against BOLA and IDOR requires acknowledging that no single control can address authorization abuse on its own. Effective protection depends on aligning controls with where authorization decisions are made and where failures become visible.

Role of traditional WAFs

Traditional WAFs continue to serve an important role at the perimeter. They reduce exposure to common web-based threats and help ensure baseline request hygiene.

However, they should not be relied on to detect or prevent object-level authorization failures. These controls operate without awareness of application data, identity-to-object relationships, or business logic. Their role in defending against BOLA and IDOR is indirect at best.

Role of API WAFs

API WAFs improve coverage by enforcing API contracts and validating structured payloads. They reduce the likelihood of abuse caused by malformed requests, unexpected fields, or uncontrolled access patterns at the boundary.

For authorization-related risks, API WAFs provide partial protection. They can restrict access to endpoints and apply identity-aware controls, but they cannot determine whether a specific identity is entitled to access to a specific object. That decision depends on runtime context that exists beyond the boundary.

Role of runtime API security

Runtime API security addresses the gap left by edge-based controls. By observing how APIs are used in production, it becomes possible to correlate identities with object access over time and detect authorization abuse that remains invisible at the request level.

This approach enables:

• Detection of unauthorized object access patterns
• Identification of gradual or distributed enumeration
• Visibility into uneven enforcement across services
• Early warning of data exposure that complies with schemas and rate limits

Runtime visibility does not replace perimeter enforcement. It provides the behavioral context required to detect failures that occur after access is granted.

Defense in depth for authorization risks

BOLA and IDOR are best addressed through layered controls. Perimeter defenses reduce noise. API boundary enforcement limits misuse. Runtime visibility detects abuse that emerges from normal-looking activity.

Each layer has a defined role. Expecting any one control to compensate for missing visibility at another layer leads to blind spots.

Conclusion: Authorization Failures Are a Visibility Problem

BOLA and IDOR attacks persist because they exploit a gap between request validation and authorization enforcement. They do not rely on malformed input or suspicious traffic. They rely on valid identities accessing objects they should not.

Traditional WAFs and API WAFs are not failing in their intended roles when these attacks occur. They are operating as designed, evaluating requests at the boundary without insight into how authorization is applied or how access patterns evolve over time.

In API-driven systems, authorization failures are behavioral. They unfold across requests, identities, and services. Detecting them requires visibility into how APIs are actually used in production, not just how they are defined or protected at the edge.

As enterprises continue to expose business logic through APIs, authorization becomes a system-level concern rather than a request-level one. Security models must evolve accordingly, shifting from isolated inspection toward continuous observation of access behavior.

This is not a call to abandon existing controls. It is a recognition that authorization abuse cannot be addressed without understanding what happens after requests are allowed. In modern API environments, visibility is the prerequisite for control.