Notifications
Clear all
Topic starter
02/08/2026 12:14 pm
TL;DR: API traffic has grown 168% in the past year and 94% of companies report an API security problem in production, according to the State of API Security report Q3 2022, underscoring how quickly shadow APIs, business logic abuse, and authorization flaws expand attack surface. Traditional WAF and gateway controls are not enough when attacker activity looks like normal API traffic and machine-to-machine access bypasses assumptions built for human workflows.
NHIMG editorial — based on content published by Salt: API security strategy questions for modern organisations
By the numbers:
- API traffic has grown 168% in the past year.
- 94% of companies reporting they have suffered an API security problem in production in the same period.
Questions worth separating out
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 shadow APIs create more risk than normal monitored traffic?
A: Shadow APIs bypass the assumptions behind monitoring because the organisation does not know they exist, so no one has reliably reviewed their authentication, authorisation, or data exposure.
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
- Implement continuous API discovery Build automated discovery for internal, external, partner, shadow, and zombie APIs, and reconcile the results against service ownership records and retirement workflows.
- Test object-level authorisation continuously Add runtime checks and negative testing for broken object level authorization, including tenant-to-tenant access, object ID manipulation, and privilege reuse across workflows.
- Map machine credentials to API ownership Tie tokens, keys, certificates, and service accounts to named business owners so every API call path has a human accountable for scope, rotation, and retirement.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- A structured checklist for API discovery across internal, partner, and customer-facing services.
- The vendor's explanation of why BOLA evades WAF and gateway controls in practice.
- More detail on shift-left testing limits and when runtime analysis becomes essential.
- The source article's breakdown of accountability across development, application, and security teams.
👉 Read Salt's analysis of API security visibility gaps and runtime controls →
API security visibility and runtime detection: are your controls keeping up?
Explore further
02/08/2026 1:17 pm
API sprawl has become an identity problem as much as an application problem. When APIs change faster than governance records, teams lose visibility into who or what is allowed to call them. That creates a control gap across machine identity, authorisation, and decommissioning. The practical conclusion is that API security must be governed as an identity and lifecycle issue, not just as traffic monitoring.
A question worth separating out:
Q: Who is accountable when API access controls fail?
A: Accountability should sit with the team that owns the API lifecycle, including design, deployment, access scope, and retirement. Security may set policy, but engineering and product owners must own the data and behaviour exposed by each interface. Without explicit ownership, APIs tend to outlive their controls and inherit stale permissions.
👉 Read our full editorial: API security visibility gaps are outpacing legacy controls
