API gateway vs WAF: why perimeter controls miss API abuse

At a glance

What this is: This is an independent analysis of why API gateways and WAFs do not stop logic-driven API abuse, with LEVO arguing that perimeter controls miss object-level authorization and data-access failures.

Why it matters: For IAM, PAM, and broader security teams, the issue is that authenticated API calls can still abuse identities, roles, and entitlements even when gateway and WAF controls appear healthy.

By the numbers:

• Gartner estimates that by the end of 2025, more than half of all data breaches will involve APIs.
• Postman’s State of the API Report shows that over 90% of organisations now depend on APIs for revenue generating workflows.
• IBM’s 2024 Cost of a Data Breach Report found that the average global breach now costs USD 4.88 million.

👉 Read LEVO's analysis of API gateway and WAF blind spots in modern API security

Context

APIs have become the control point where business logic, customer data, and partner workflows intersect, so API security is now a governance problem rather than just a perimeter problem. In practice, gateway and WAF deployments can look effective while still leaving object-level authorization, role misuse, and data overexposure unaddressed, which makes the API layer especially relevant to identity and access governance.

The primary failure in this article is not the absence of traffic controls, but the assumption that traffic controls can enforce entitlement decisions inside the application. That matters to IAM practitioners because API calls increasingly carry authenticated identities, delegated access, and machine-to-machine permissions that need governance beyond edge filtering.

Key questions

Q: What breaks when API security depends only on gateways and WAFs?

A: Teams lose visibility into business logic abuse, object-level authorisation failures, and low-and-slow reconnaissance that looks legitimate at the transaction layer. Gateways and WAFs still have value, but they cannot reliably judge intent, object ownership, or whether a valid session is being used outside its intended scope. That leaves a major gap in runtime control.

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: What are the signs that an API authorization control is failing in practice?

A: Common warning signs include endpoints returning valid data without a token, access to records that should be scoped to another user, and responses that expose credentials or keys in configuration data. Another indicator is when iterating a parameter reveals large volumes of records in predictable increments. Those patterns suggest broken object or function level authorization, not just a minor configuration issue.

Q: How should security teams govern API access as a non-human identity?

A: Security teams should inventory APIs as identities, assign an accountable owner, and enforce lifecycle controls for issuance, rotation, expiry, and revocation. The goal is to make access explicit and reviewable rather than hidden in code, pipeline variables, or shared credentials. Without that discipline, machine access becomes unmanaged trust instead of governed identity.

Technical breakdown

API gateways: traffic control, not entitlement control

An API gateway is a front-door control plane that authenticates requests, applies routing rules, enforces quotas, and forwards traffic to backend services. It is designed for consistency, availability, and operational control across many APIs. What it cannot do is decide whether a caller should see a specific record, change a specific object, or invoke a sensitive business function after the request passes initial checks. That decision belongs to the application and its data model, which is why gateway success can coexist with API abuse.

Practical implication: treat the gateway as a perimeter control and move entitlement decisions into service-layer authorization and policy enforcement.

WAFs parse requests, but not business meaning

A WAF inspects HTTP and HTTPS traffic for known malicious patterns, malformed payloads, injection attempts, and protocol abuse. Modern WAFs can parse JSON and XML, and some can recognise API schemas, but they still evaluate the request largely as a message format problem. They do not reliably understand object ownership, role-specific business rules, or whether a seemingly valid request is appropriate for the authenticated identity. That makes them useful for blocking obvious attack strings, but weak against logic abuse that uses legitimate syntax.

Practical implication: keep the WAF for input filtering, but add runtime checks that validate identity, object ownership, and workflow state.

Why valid credentials still produce API breaches

The article’s core point is that many API attacks never need malformed traffic. Attackers use valid credentials, valid endpoints, and ordinary-looking requests to enumerate records, abuse roles, or extract sensitive data at scale. Perimeter tools often accept those requests because nothing in the packet looks illegal. The failure is one of authorization context, not transport security. In identity terms, the request is authenticated, but the entitlement decision is wrong or incomplete, which is why API abuse often looks like normal user activity until the data loss becomes visible.

Practical implication: log and evaluate object-level access patterns, not just authentication success and request volume.

Threat narrative

Attacker objective: The attacker wants to use legitimate API access to enumerate objects, extract sensitive records, or abuse business workflows without triggering gateway or WAF controls.

1. Entry occurs through a legitimate API call carrying valid credentials, so the request passes gateway authentication and WAF syntax checks.
2. Escalation happens when the attacker modifies identifiers, roles, or workflow inputs to reach data or functions the application should not expose.
3. Impact is large-scale data extraction or workflow abuse that stays within allowed request patterns and bypasses perimeter detection.

NHI Mgmt Group analysis

API security has moved from perimeter filtering to entitlement governance. The article shows why gateways and WAFs are necessary but insufficient when identity and data access decisions happen inside services. In practice, the control gap is not traffic acceptance but authorization fidelity across objects, roles, and workflows. Practitioners should read this as a governance problem, not an inspection problem.

Object-level authorization is the named failure mode enterprises keep underestimating. API attacks frequently succeed because authenticated callers can still access objects they do not own or should not see. That is a classic control failure in API design, and it sits close to IAM because entitlements are being evaluated too late, or not at all. The practitioner conclusion is simple: access policy must follow the object, not just the request.

Runtime API abuse is where identity control and application control converge. The article’s strongest point is that valid identities can be weaponised through legitimate APIs without any obvious anomaly at the edge. That makes API telemetry, behavioural detection, and policy enforcement part of identity governance, especially where machine-to-machine access and delegated workflows are involved. Teams should treat API runtime controls as an extension of access governance, not as a separate security island.

Named concept: perimeter-aware API security creates a false sense of coverage. Organisations often believe that gateway authentication plus WAF filtering equals API security, but that model only protects request admission. It does not govern the semantics of data use, which is where modern breaches occur. The practical conclusion is that security architecture must measure entitlement correctness, not just traffic cleanliness.

Identity teams must own machine-to-machine access context. As APIs increasingly carry service accounts, tokens, and delegated identities, IAM and PAM teams need visibility into which identities can reach which objects and functions. Without that mapping, API abuse becomes an identity problem hidden inside application traffic. Practitioners should extend identity governance into API authorisation reviews and runtime monitoring.

What this signals

Perimeter controls will keep looking successful while entitlement risk grows underneath them. As APIs become the main route to business data, the next failure mode is not unauthenticated attack traffic but authorised abuse that passes every gateway check. Teams should prepare for more emphasis on runtime authorisation, behavioural detection, and policy validation across service identities and delegated access.

API governance is converging with identity governance. Once service accounts, tokens, and workflow credentials are the real actors behind API calls, the operational question becomes who can do what to which object, and under what conditions. That is where API monitoring, access reviews, and privilege scoping need to meet each other.

Object-level controls will increasingly define whether an API programme is defensible. The organisations most exposed are the ones that can describe their perimeter stack but not prove entitlement correctness at runtime. Practitioners should expect auditors and incident responders to ask for evidence that object ownership, role constraints, and data access policies are enforced where the data is actually used.

For practitioners

• Map object-level authorization paths Inventory which API endpoints expose customer records, orders, payments, or administrative actions, then verify that ownership checks occur inside the service, not only at the gateway.
• Test for valid-request abuse scenarios Use attack simulations that modify object IDs, role parameters, and workflow states while keeping requests syntactically valid, because those are the cases perimeter tools often miss.
• Extend IAM review to machine API identities Review service accounts, OAuth clients, and tokens that can call business-critical APIs, and confirm that each identity has narrowly scoped access tied to the minimum objects required.
• Monitor for data enumeration and role misuse Alert on sequential object access, unusual access depth, and repeated requests across adjacent records, since those patterns often indicate abuse that a WAF will not classify as malicious.

Key takeaways

• API gateways and WAFs reduce exposure at the edge, but they do not enforce the entitlement decisions that determine whether a caller should see a specific object or workflow.
• The real breach pattern is valid-request abuse, where authenticated identities use ordinary-looking API calls to enumerate records, misuse roles, and extract data at scale.
• Security teams need runtime authorisation, object-level access checks, and identity governance for service accounts and tokens, not just perimeter filtering.

Key terms

• API gateway: An API gateway is the enforcement layer that sits in front of backend services and decides how requests are authenticated, authorized, routed, logged, and rate limited. In partner ecosystems it functions as a control point for machine access, not just a traffic router, because it can unify identity and transport checks.
• Web Application Firewall: A web application firewall inspects HTTP traffic and applies rules to detect or block malicious requests and responses. Unlike a network firewall, it understands application-layer content such as headers, parameters, and body fields, which lets it catch attacks like injection and path probing.
• 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.
• API-Based Email Security: API-based email security integrates with the mail platform through application interfaces rather than sitting in front of traffic. This lets security teams inspect delivered messages, automate remediation, and connect email actions to mailbox and identity context in cloud-native environments.

What's in the full article

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

• Step-by-step explanation of how API gateways, WAFs, and runtime security differ in enforcement scope.
• Detailed breakdown of the gateway and WAF failure modes that allow object-level authorization abuse.
• Side-by-side examples showing where business logic validation must occur inside the application.
• Operational comparison table that helps teams decide which control belongs at the edge and which belongs in the service layer.

👉 LEVO's full article covers the gateway, WAF, and runtime control differences in practical detail.

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 security practitioners connect identity control to the broader access and lifecycle decisions that underpin modern application security.