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.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “API Gateway Security: What is it and is it Enough?”.
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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:37 pm
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.
A few things that frame the scale:
- 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.
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