API authorization failures expose the limits of WAF-based defense

At a glance

What this is: LEVO argues that API security incidents are now driven more by authorization failures like BOLA and IDOR than by perimeter evasion or malformed traffic.

Why it matters: This matters because IAM, PAM, and application security teams cannot rely on WAFs alone when valid identities can traverse APIs into objects they are not entitled to access.

By the numbers:

• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.

👉 Read LEVO's analysis of why API authorization failures defeat WAF-based defense

Context

API-first architecture has shifted a large share of enterprise risk from the network edge into application logic, where authorization is decided per request and often per object. That creates a governance gap because valid authentication no longer guarantees valid access, and perimeter controls are usually blind to the relationship between identity, object, and context.

BOLA and IDOR are not exotic exploit techniques. They are failures of object-level authorization in systems that expose business data directly through identifiers, which means IAM and AppSec teams need runtime visibility into who can act on what, not just whether the request looks well formed.

Key questions

Q: What breaks when GraphQL APIs do not enforce object-level authorization?

A: The application can authenticate a user and still allow that user to access or change records they do not own. In GraphQL, one mutation may touch several objects, so missing checks at any layer can expose data, enable cross-account actions, or allow fraudulent transactions. The fix is server-side entitlement validation on every sensitive object, not just at login.

Q: Why do valid API requests still create breach risk?

A: Valid API requests still create breach risk because authentication proves the caller is known, not that the caller is entitled to the specific object. If the application accepts an identifier or booking code as proof of access, attackers can modify that value and harvest data without tripping traditional perimeter controls.

Q: How do security teams find object-level authorization failures?

A: They need to test every method and route variant against the same record under different users, tenants, and roles. Manual testing should include direct requests to internal handlers, not only the intended UI path. If a request can reach a record without proving ownership, the authorization model is incomplete.

Q: Should organisations rely on WAFs or API WAFs to stop BOLA and IDOR?

A: No. WAFs and API WAFs are useful for request hygiene, schema enforcement, and boundary control, but they cannot reliably determine whether a caller is entitled to a specific object. They reduce noise, while the authorization decision still has to be enforced in the application or service.

Technical breakdown

Why BOLA and IDOR bypass request-focused controls

Broken Object Level Authorization and Insecure Direct Object References exploit a simple asymmetry: the request is valid, but the access decision is wrong. WAFs inspect syntax, patterns, and signatures, while the authorization decision depends on ownership, tenancy, role, and application context. If the API accepts an identifier and only checks that the object exists, the control chain stops too early. This is why these attacks often succeed without malformed payloads, unusual rates, or obvious protocol abuse. The weakness sits inside the application’s decision logic, not at the perimeter.

Practical implication: move object authorization into the enforcement path, not just the edge.

Why APIs make object-level authorization harder to govern

APIs expose business objects directly, which means every endpoint becomes a potential authorization boundary. In modern systems, those boundaries are distributed across microservices, partner integrations, and automation clients, each with different assumptions about scope and identity. Stateless request handling makes the problem worse because the service has no memory of prior validation unless it rechecks every call. A single endpoint that omits ownership checks can create a breach path even if adjacent services are correct. The result is uneven enforcement, not just isolated coding mistakes.

Practical implication: map authorization consistency across endpoints, services, and clients as a governance task.

Why API WAFs improve hygiene but not entitlement decisions

API WAFs are better than generic perimeter controls because they understand structured payloads, JSON fields, and token-based identity. They can validate schema, block malformed input, and improve boundary enforcement. But schema validation is not the same as entitlement validation. An API WAF can tell you that a request is syntactically correct and authenticated, but it cannot reliably know whether the caller is authorised for that specific object. That distinction is why request-level inspection reduces noise without closing the core authorization gap.

Practical implication: treat API WAFs as a control layer, not the source of truth for access decisions.

Threat narrative

Attacker objective: The attacker seeks unauthorized access or modification of application data while staying inside normal request patterns.

1. Entry occurs through a legitimate authenticated API request that uses a valid endpoint and well-formed object reference.
2. Escalation happens when the caller changes the object identifier or reuses a direct reference outside their entitlement scope.
3. Impact follows when the application returns, updates, or deletes data that belongs to another user, tenant, or business context.

NHI Mgmt Group analysis

Authorization failure is now the decisive API security problem. Perimeter tooling can filter malformed traffic, but it cannot prove that a valid identity is entitled to a specific object. That shifts the centre of gravity from edge inspection to entitlement enforcement, which is exactly where many enterprises are least mature. For IAM and AppSec leaders, the practical conclusion is that object-level access control must be treated as a runtime control plane, not a code review checkbox.

Object-level authorization debt is a better name for the real risk than BOLA alone. BOLA and IDOR describe symptoms, but the deeper issue is that enterprises accumulate inconsistent authorization logic across services, endpoints, and clients. That debt grows whenever teams duplicate checks, rely on UI-layer restrictions, or assume upstream validation is enough. The governance lesson is clear: if the same identity can reach different objects depending on the path taken, the control model is already fragmented.

Runtime correlation is the missing layer in API governance. Static policy and perimeter filtering do not reveal whether an identity is gradually enumerating objects, moving across sessions, or exploiting inconsistent enforcement. This is where identity telemetry and behavioural baselines become relevant to application security. Teams that already govern NHI and service identities will recognise the pattern: the problem is not just who authenticated, but what that identity was allowed to touch at the moment of access.

API-first design expands the blast radius of weak entitlement design. As applications expose more business objects directly to partners, mobile clients, and automation, each exposed identifier becomes a governance dependency. That makes authorization a cross-functional issue involving IAM, application engineering, and API security operations. The practitioner takeaway is to treat every object reference as an access control decision, not just a routing detail.

Runtime entitlement drift is the named concept that matters here. It describes the gap between the access rules teams believe they have and the object-level decisions the application actually makes in production. This drift is hard to see in test environments because it emerges from real identity paths, edge cases, and distributed services. The practical conclusion is to continuously verify authorisation outcomes against live request behaviour, not just against design intent.

What this signals

Object entitlement is becoming a runtime governance problem, not just an AppSec concern. As API estates grow, teams will need continuous verification of identity-to-object relationships rather than one-time code review. That makes control evidence, auditability, and behavioural telemetry more important than perimeter confidence, especially where APIs expose business objects directly.

The next maturity step is to align API security with identity governance. That means linking access decisions, service identities, and resource ownership to a single evidence trail that can be inspected after the fact and enforced in production.

Runtime entitlement drift will matter more as automation and partner access expand API usage. If an identity can reach the wrong object through one path but not another, the policy model is already inconsistent and the risk is already live.

For practitioners

• Instrument object-level access checks Log every decision that grants access to a business object, including the identity, object ID, endpoint, and enforcement outcome, so you can detect where ownership checks are missing or inconsistent.
• Reconcile authorization logic across services Compare access rules across APIs that touch the same resource type, and flag any endpoint that relies on UI-layer controls, upstream trust, or partial validation.
• Baseline normal identity-to-object behaviour Build behavioural baselines for which identities normally access which object classes, then alert on unusual cross-tenant, cross-account, or cross-object access sequences.
• Test for broken ownership checks in production paths Exercise the live API with valid credentials and alternate object identifiers to confirm that ownership and scope are enforced after authentication, not before it.

Key takeaways

• BOLA and IDOR are authorization failures, not traffic anomalies, which is why perimeter controls often miss them.
• The scale of the problem is driven by API-first design, distributed authorization logic, and valid requests that still reach the wrong object.
• Practitioners need runtime entitlement enforcement and behavioural visibility, not just WAF coverage and schema validation.

Key terms

• Broken Object Level Authorization: Broken Object Level Authorization is an API failure where a request is authenticated but the application does not verify whether the caller is allowed to access the specific object referenced. It is an entitlement problem, not a transport or syntax problem, and it commonly leads to data exposure or unauthorized modification.
• Insecure Direct Object Reference: Insecure direct object reference is an access control flaw where an application exposes an identifier that allows callers to reach records or objects they should not be able to access. In practice, it means the system trusts the request too much and fails to verify object-level permission on each access.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Runtime Entitlement Drift: Runtime entitlement drift is the gradual expansion of an agent’s permissions across tasks, environments, or workflows without a deliberate reset. It often starts with temporary exceptions or broad defaults, then becomes persistent over time, creating a larger blast radius than the original use case required.

What's in the full article

LEVO's full article covers the operational detail this post intentionally leaves for the source:

• Endpoint-by-endpoint breakdown of how BOLA and IDOR manifest in live API traffic
• Request-inspection examples showing why traditional WAFs miss object-level entitlement failures
• Operational distinctions between API WAF coverage and runtime authorization enforcement
• Implementation considerations for correlating identity, object, and context across services

👉 LEVO's full post covers the technical breakdown of BOLA, IDOR, and runtime authorization gaps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners translate identity controls into operational governance across modern security programmes.