API gateways expose the limits of transaction-only API security

At a glance

What this is: This is Salt’s analysis of why API gateways are useful for management and basic controls but insufficient against modern API attacks that exploit business logic and transaction-level blind spots.

Why it matters: It matters because identity, access control, and authorisation decisions inside APIs affect both human and non-human access paths, and gateway-only models leave teams exposed to abuse that looks legitimate at the request level.

By the numbers:

• The Salt Security Q3 2022 State of API Security report showed that the average number of APIs per Salt customer grew 82% over last year to more than 162 in July 2022.
• 168%.
• Businesses that utilized APIs were more profitable over the past decade, experiencing 12.7% higher growth in market capitalization growth than those that did not use APIs.
• Salt’s survey found that 54% of respondents are relying on their API Gateway for security, yet 82% don’t believe their existing tools are very effective in preventing API attacks.

👉 Read Salt’s analysis of why API gateways miss modern API attacks

Context

API gateway security is often treated as the main control for API estates, but gateway design focuses on routing, policy enforcement, and per-request inspection rather than deep behavioural context. That creates a governance gap when attackers use valid requests, subtle parameter manipulation, and low-and-slow reconnaissance to reach business logic flaws. In identity terms, the boundary matters because API requests often carry authentication and authorisation decisions for both human users and non-human identities such as service accounts and integrations.

Salt’s article argues that teams need discovery, runtime analysis, and feedback into development because modern API abuse is rarely visible in isolation. That is consistent with broader NHI governance patterns: high volumes of machine-to-machine access demand controls that understand context, not just signatures. For practitioners, the question is not whether a gateway exists, but whether it can support the visibility and correlation needed to detect misuse across changing API estates.

Key questions

Q: What breaks when organisations rely on an API gateway alone?

A: An API gateway alone leaves the internal service layer largely governed by network assumptions. That means east-west calls may be trusted too easily, workloads may use static credentials, and internal movement can go unobserved. The result is a perimeter-controlled environment with a weak backend trust model, which is a common failure pattern in distributed systems.

Q: Why do API gateways struggle with broken object level authorisation?

A: BOLA attacks work because the request often looks structurally correct. A gateway sees a legitimate call, while the abuse happens in the relationship between identifiers, parameters, and application logic. Without deeper context and cross-request analysis, the control has no reliable way to infer that the user is trying to access another object’s data.

Q: How can security teams tell whether API risk controls are actually working?

A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why. If the control is effective, suspicious traffic should be slowed, challenged, or blocked before it reaches core systems, while legitimate integrations continue to function normally.

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 API gateways miss business logic attacks

API gateways are built to sit in front of APIs, apply policy, and route traffic. They usually inspect each request transaction in isolation, which works for rate limiting, known signatures, and coarse access controls. The problem is that many API attacks are not malformed requests. They are valid requests with malicious intent, such as parameter tampering, object reference abuse, or sequencing that exploits business logic. Without cross-request correlation and baselining, the gateway cannot distinguish a genuine user journey from an attacker slowly probing the application.

Practical implication: treat the gateway as a front door control, not as your primary detection layer for API abuse.

How context and correlation expose API reconnaissance

Modern API security depends on understanding normal behaviour over time. That means correlating millions of API calls, learning which fields should match, which sequences are normal, and which changes indicate probing. This is especially important for low-and-slow reconnaissance, where an attacker intentionally behaves like a real client to avoid threshold-based alerts. AI and machine learning are useful here only when they support behavioural baselines and anomaly detection tied to concrete API semantics, not generic noise reduction.

Practical implication: build runtime detection around behaviour baselines and sequence analysis, not just signature matching.

Why shadow APIs and zombie APIs expand the attack surface

Discovery is a core requirement because organisations often lose track of all active APIs as systems evolve. Shadow APIs are undocumented or unmanaged interfaces, while zombie APIs are old endpoints that remain reachable after they should have been retired. Both create exposure because governance teams cannot protect what they cannot inventory. Continuous discovery matters for partner-facing, internal, and customer-facing APIs, and it also helps identify sensitive data exposure before attackers do.

Practical implication: automate API inventory and retirement workflows so undiscovered endpoints do not become permanent risk.

Threat narrative

Attacker objective: The attacker wants to bypass authorisation logic and reach data or functions that should be inaccessible, while remaining inside apparently legitimate API traffic.

1. Entry begins with a valid API request, often made by an authenticated user or non-human integration that passes gateway checks because the structure appears normal.
2. Escalation occurs when the attacker iterates through parameters, object identifiers, or request sequences to discover weak authorisation logic or hidden API behaviour.
3. Impact follows when the attacker reads, modifies, or exfiltrates data through the API without triggering controls that only inspect requests in isolation.

NHI Mgmt Group analysis

Transaction-only controls create a visibility gap that API security teams keep underestimating. A gateway can enforce policy at the edge, but it cannot reliably reconstruct intent across multiple calls or sessions. That leaves business logic abuse outside its view, especially when attackers stay within expected request patterns. Practitioners should treat transaction-only inspection as a control boundary, not a security end state.

API sprawl is now an access governance problem, not just an application problem. As API estates expand, undocumented endpoints, stale integrations, and third-party connections create unmanaged access paths that resemble NHI sprawl in other environments. The security issue is not only exposure, but entitlement drift across systems that still trust old paths. The result is a broader authorisation surface than most teams can account for. Practitioners should align API inventory with identity governance and offboarding discipline.

Business logic attacks reward defenders who understand the application as a system of decisions. Signature models help against known bad input, but they are weak against abuse of lawful workflows. That means defenders need policy, observability, and analytics aligned to how the API actually makes decisions. In practice, the winning control is not more blocking rules, but richer context about normal and abnormal request paths.

Runtime detection is becoming the control layer that separates managed APIs from exposed APIs. If a security programme cannot continuously discover, baseline, and correlate API behaviour, it cannot claim meaningful runtime coverage. The market is moving toward controls that combine discovery, context, and response. Practitioners should expect API governance to converge with broader data, identity, and runtime security programmes.

API gateway security and API security are no longer interchangeable terms. Gateways remain necessary for management and traffic mediation, but they do not solve the full authorisation and abuse problem. That distinction matters for budget, ownership, and architecture decisions. Practitioners should document the divide clearly so control ownership does not become ambiguous during incidents.

What this signals

API governance is converging with identity governance because every API is also an access path. Where service accounts, OAuth grants, and integrations sit behind API traffic, the operational problem is no longer just application protection. It becomes entitlement visibility, lifecycle control, and response to misuse across human and non-human identities. Teams that already manage NHI exposure should extend that discipline into API inventories and runtime monitoring.

Low-and-slow API abuse creates a detection-response latency problem. A control that only reacts to single requests will always be late against attacks that unfold over time. Practitioners should think in terms of behavioural windows, not events, and align detection with the tempo of API exploitation. That is where correlation, baselining, and offboarding discipline start to matter together.

Transaction-level inspection is a useful perimeter control, but it is not a governance model. The practical implication is that security leaders need a shared view across gateway policy, application logging, and identity entitlements. Without that, API risk stays fragmented across teams and no one can explain who can do what, through which interface, and under what conditions.

For practitioners

• Map gateway coverage against your real API estate Inventory partner-facing, internal, and customer-facing APIs, then compare that list to what the gateway actually sees. Retire undocumented endpoints and confirm that zombie APIs are removed from routing and access paths. Use the inventory as a governance baseline for change control and offboarding.
• Correlate requests across sessions and time windows Add runtime analytics that can compare parameter values, request sequences, and response patterns across many calls. Focus on detecting broken object level authorisation, low-and-slow reconnaissance, and field mismatch patterns that a single transaction will not reveal.
• Separate perimeter policy from runtime detection Keep rate limiting, authentication, and signature blocking at the gateway, but add a dedicated detection layer for behavioural anomalies and business logic abuse. Write the operating model so teams know which control is expected to prevent, detect, and investigate each attack class.
• Feed runtime findings back into development Use production detections to prioritise API fixes in the development cycle. Align defect triage with the paths attackers actually probe, especially where testing missed hidden authorisation flaws or inconsistent field handling.

Key takeaways

• API gateways are necessary, but they are not sufficient for modern API security.
• Business logic abuse and broken object level authorisation demand behavioural context, not just signatures.
• API discovery, runtime correlation, and identity-aware governance are now core controls for sprawling API estates.

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.
• 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.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.

What's in the full article

Salt’s full article covers the practical detail this post intentionally leaves for the source:

• Gateway-by-gateway security feature comparison, including rate limiting, tokenisation, and policy enforcement behavior
• Step-by-step explanation of how BOLA-style requests pass through gateway controls
• Operational framing for layering API discovery, runtime protection, and development feedback
• Salt’s examples of how traffic mirroring supports discovery and runtime detection

👉 Salt’s full article covers gateway limitations, BOLA detection, and the layering model for API security.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and access lifecycle control. It is designed for practitioners who need to connect identity discipline to broader security architecture and governance.