Notifications
Clear all
Topic starter
02/08/2026 9:44 am
TL;DR: API gateways provide routing, rate limiting, and basic policy enforcement, but they miss low-and-slow abuse and business logic attacks such as broken object level authorisation, according to Salt Security. The practical lesson is that API security now depends on continuous context, discovery, and runtime analysis, not just perimeter controls.
NHIMG editorial — based on content published by Salt: API gateway security and why dedicated API security is still needed
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.
- During the same period, overall API traffic per customer grew 168%.
Questions worth separating out
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.
Q: Why do API gateways struggle with broken object level authorisation?
A: BOLA attacks work because the request often looks structurally correct.
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.
Practitioner guidance
- 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.
- Correlate requests across sessions and time windows Add runtime analytics that can compare parameter values, request sequences, and response patterns across many calls.
- 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.
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
👉 Read Salt’s analysis of why API gateways miss modern API attacks →
API gateways and BOLA risk: what security teams need to know?
Explore further
02/08/2026 12:37 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: API gateways expose the limits of transaction-only API security
