Notifications
Clear all
Topic starter
21/08/2026 5:00 pm
TL;DR: A WAF cannot reliably stop BOLA, shadow APIs, or east-west abuse because modern API attacks exploit authorization, inventory drift, and workload identity rather than simple request signatures, according to AccuKnox. The practical shift is from perimeter filtering to continuous discovery, behavioural monitoring, and identity-aware enforcement.
NHIMG editorial — based on content published by AccuKnox: API Security Beyond WAF, Why Runtime Context Defines Modern API Security
By the numbers:
- More than 50% of recorded cybersecurity exploits in 2024 were API-related, roughly double the 2023 volume.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
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 APIs need stronger identity controls than standard OAuth deployments provide?
A: Standard OAuth deployments often prove that a token was issued, not that the original client is still presenting it.
Q: How can security teams tell whether API discovery is actually working?
A: API discovery is working when newly created or changed endpoints appear quickly in the inventory, each has an accountable owner, and sensitive-data handling is visible in the same record.
Practitioner guidance
- Map API inventory from runtime telemetry Use Kubernetes telemetry, service mesh data, or eBPF traces to identify active, shadow, zombie, and orphan APIs before you tune enforcement rules.
- Move authorization checks to the policy layer Enforce object ownership and entitlement checks at the point of access so BOLA cannot pass as a valid request.
- Bind API decisions to workload identity Use JWT claims, service identity, and CNAPP context to apply different policy to internal services, public clients, and machine-to-machine calls hitting the same endpoint.
What's in the full article
AccuKnox's full article covers the operational detail this post intentionally leaves for the source:
- Runtime deployment examples for WAF, gateway, and service-mesh integration in production API stacks
- Detailed mapping of OWASP API Top 10 categories to specific runtime and identity controls
- Practical correlation patterns for CNAPP, workload identity, and sensitive data-store access
- Compliance-focused evidence examples for audit-ready runtime API monitoring
👉 Read AccuKnox's analysis of why API security must go beyond WAF →
API security beyond WAF: are your runtime controls keeping up?
Explore further
21/08/2026 5:16 pm
API security has become an identity governance problem as much as a traffic-filtering problem. The article is right to separate WAF value from modern API defence. Once requests are authenticated, the key question becomes whether the calling identity is entitled to the object, service, or data store it can reach. That is a governance issue, not just a detection issue, and it applies equally to human users, service accounts, and machine-authenticated workloads.
A question worth separating out:
Q: Who is accountable when a public API leaks data through valid access?
A: Accountability usually spans application owners, IAM or platform teams, and security leadership, because the failure is shared between access design, endpoint logic, and monitoring. In regulated environments, the organisation must also be able to show that access controls and logging were proportionate to the sensitivity of the data involved.
👉 Read our full editorial: API security beyond WAF needs runtime identity and context
