API gateways expose the limits of transaction-only API security

At a glance

What this is: Salt argues that API gateways help manage and filter API traffic, but they cannot reliably stop BOLA and other low-and-slow attacks that require cross-request context.

Why it matters: For IAM, NHI, and application security teams, the key issue is that transaction-level controls do not prove authorisation correctness, so gateway coverage alone leaves business-logic abuse and delegated access paths exposed.

By the numbers:

• APIs per Salt customer grew 82% over last year to more than 162 in July 2022.
• Overall API traffic per customer grew 168% during the same period.
• 54% of respondents are relying on their API Gateway for security.
• 82% don’t believe their existing tools are very effective in preventing API attacks.

Context

An API gateway is a front-door control for routing, basic authentication, rate limiting, and policy enforcement across API traffic. That model helps with scale and standardisation, but it only sees one request at a time, which makes it weak against attacks that depend on sequence, context, and business logic.

For identity and access teams, the important distinction is that gateway checks are not the same as authorisation assurance. BOLA, shadow APIs, and low-and-slow reconnaissance can all pass through a valid transaction boundary while still violating intended access rules, so governance has to extend beyond perimeter controls into runtime analysis and inventory visibility.

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 low-and-slow API attacks evade rate limits and signatures?

A: Low-and-slow attacks evade those controls because each request can look normal on its own. The malicious pattern emerges only when many requests are correlated over time, especially during reconnaissance and parameter testing. Static rules are tuned to obvious anomalies, while business logic abuse often depends on context across sessions and endpoints.

Q: What are the signs that API discovery and documentation are failing in practice?

A: Common warning signs include delayed application rollouts, incomplete or missing documentation, outdated OpenAPI files, and APIs that change faster than inventories are updated. Another signal is when security teams cannot reliably identify which endpoints expose sensitive data or which environments contain active interfaces. Those gaps usually mean the discovery process is manual, partial, or non continuous.

Q: How should teams balance API gateways and dedicated API security tools?

A: Use the gateway for routing, coarse policy, and request mediation, then layer dedicated API security for behavioural baselining, discovery, and attack correlation. The two controls are complementary, not interchangeable. Teams should define which layer owns prevention, which owns detection, and how findings move into remediation.

Technical breakdown

Why transaction-only API controls miss BOLA abuse

API gateways are built to inspect a request, apply a rule, and forward or block it. That works well for known signatures, throttling, and coarse policy enforcement, but it fails when the attack is distributed across many requests and only becomes visible when fields are compared over time. Broken object level authorisation exploits that gap by keeping the request structurally valid while changing the object or user reference. The gateway sees compliant syntax; the server sees an apparently authenticated caller; the abuse sits in the relationship between parameters, not in any single packet. Practical implication: detection has to correlate request context, object references, and response behaviour across sessions.

Practical implication: Treat gateway inspection as a gate, not a verdict on authorisation correctness.

How low-and-slow reconnaissance hides in normal API traffic

Attackers often probe APIs gradually to map endpoints, discover business logic, and test whether identifiers can be swapped or replayed. Because each probe can look legitimate on its own, rate limits and static signatures may never trigger. This is especially true where the API is already heavily used and the attacker blends into ordinary consumer or partner traffic. The security problem is not just volume but temporal structure: malicious intent emerges only after stitching together many otherwise ordinary calls. Practical implication: build detections that baseline behaviour for each API and flag sequences that reveal object discovery, parameter tampering, or unusual field relationships.

Practical implication: Baseline each API’s normal sequence patterns so slow probing stands out.

Why API discovery is part of the security control, not a side task

The article’s reference to shadow APIs and zombie APIs points to a governance issue, not just an inventory problem. If teams do not know every exposed API, they cannot know which identities, integrations, or data paths are still active. Discovery must therefore be continuous, because APIs change faster than manual catalogues and retired interfaces often remain reachable longer than intended. For IAM-adjacent programmes, this matters because exposed APIs become hidden authentication and authorisation surfaces, especially when service accounts or delegated tokens still work against forgotten endpoints. Practical implication: tie API discovery to runtime monitoring so unowned interfaces are visible before they are abused.

Practical implication: Continuously inventory exposed APIs and bind ownership to each live endpoint.

Threat narrative

Attacker objective: The attacker wants to bypass object-level authorisation and reach data or actions belonging to other users without tripping gateway controls.

1. Entry occurs through a legitimate API endpoint that accepts a correctly structured request, even when the caller is not entitled to the target object.
2. Credential or session use is then combined with parameter manipulation, allowing the attacker to keep the request looking valid while changing object identifiers.
3. Escalation happens when repeated low-and-slow requests reveal which identifiers, users, or business rules can be abused without triggering static gateway checks.
4. Impact is unauthorised access to other users’ data or functions through broken object level authorisation, with the gateway forwarding each individual transaction as if it were normal.

Breaches seen in the wild

• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.
• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Transaction-level API security is no longer enough when the abuse lives in the relationship between requests. Gateway controls can block obvious bad inputs, but they are structurally weak against business logic abuse that only becomes visible across a sequence of calls. That changes the control conversation from request filtering to context reconstruction. Practitioners should treat runtime correlation as a core authorisation control, not an optional detection layer.

BOLA is an authorisation failure, not just an API problem. The deeper issue is that a request can be syntactically and session-wise valid while still targeting the wrong object. That makes API security relevant to identity governance because the system is effectively trusting the caller’s session without proving object entitlement at the point of use. Teams should map object-level access decisions to the actual identity and entitlement model, not to gateway acceptance alone.

Continuous API discovery is now part of the identity surface. Shadow APIs and zombie APIs create unmanaged access paths that are easy to forget and hard to monitor. When service accounts, tokens, or partner integrations continue to reach old endpoints, the organisation has a governance problem that looks like an infrastructure problem. Practitioners should make live API inventory part of access control hygiene, because unmanaged endpoints become unmanaged identity paths.

AI-assisted correlation is becoming the practical threshold for modern API defence. The article’s argument is not that signatures are useless, but that signatures alone cannot keep pace with multi-step abuse patterns. As API estates expand, the relevant question is whether teams can observe enough traffic over enough time to identify behaviour that only makes sense in aggregate. Practitioners should assume that runtime analytics, not static blocking, is the control that separates noise from abuse.

API gateways still matter, but only as one layer in a broader control stack. The gateway remains useful for routing, oversight, and coarse enforcement, yet the article makes clear that it does not replace dedicated runtime security. That distinction is important for programme design: teams should preserve gateway governance while adding controls that understand object relationships, behavioural baselines, and exposure drift. The practical conclusion is layered control, not tool substitution.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: API Key Management Guide

What this signals

API gateway dependence is becoming a governance risk when teams mistake request filtering for authorisation assurance. The control can still reduce noise, but it cannot prove that the caller is entitled to the object or action being requested. That means security teams need to treat runtime behaviour as part of the identity surface, not just an API operations concern.

Business logic abuse is shifting API defence toward continuous observation rather than static rules. The more an environment depends on partner integrations, service accounts, and delegated access, the more important it becomes to correlate requests over time and to understand which APIs are actually live. In practice, this is where API security intersects with IAM and NHI governance.

Shadow API exposure is a lifecycle problem, not a point-in-time inventory problem. APIs do not stay stable long enough for periodic catalogues to be sufficient, so organisations need live ownership, live discovery, and live monitoring. That is the only way to close the gap between what is reachable and what is formally governed.

For practitioners

• Map API gateway coverage against BOLA exposure Identify which APIs rely on gateway-only enforcement and test whether object-level authorisation is actually validated deeper in the stack.
• Inventory shadow and zombie APIs continuously Maintain a live catalogue of partner-facing, internal, and customer-facing APIs, and assign ownership to every endpoint that can still be reached.
• Baseline request sequences for each API Use behavioural baselines to spot low-and-slow reconnaissance, parameter tampering, and other multi-request abuse patterns that single-transaction rules miss.
• Validate object-level authorisation at the application layer Test whether users can change object identifiers, user IDs, or related fields without the application detecting a mismatch in entitlement.
• Feed runtime findings back into development Use production detections to prioritise fixes for business logic flaws, then harden the affected API routes before the next release.

Key takeaways

• API gateways can help manage traffic and enforce coarse policy, but they do not reliably stop BOLA or other business logic attacks that depend on context across requests.
• Salt reports that 54% of respondents rely on their API gateway for security, yet 82% do not think their existing tools are effective at preventing API attacks.
• The practical answer is layered control: continuous discovery, behavioural analysis, and runtime inspection have to complement gateway governance if organisations want to reduce API abuse.

Key terms

• 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 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.
• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Zombie API: A zombie API is a deprecated or abandoned interface that remains accessible after the organisation believes it should be retired. It is risky because old permissions, secrets, or backend trust can survive the business purpose, turning legacy access into an active exposure.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to govern machine identities, access paths, and delegated trust across modern environments.