Topic starter
02/08/2026 12:21 pm
TL;DR: 403 spikes point to API controls failing when authentication, scopes, or endpoint validation are too weak, Salt Security reports. API posture, behavioural detection and identity policy need to work together so runtime access stays inside enforced boundaries.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “90 Days of Learning, Good Surprises and Extreme Optimism”.
By the numbers:
- According to Salt, there was a 400% increase in unique API attackers in the last year.
Key questions
Q: Why do APIs create so much risk in modern web applications?
A: APIs often carry the real business logic of an application, including data access, account actions, and administrative functions.
Q: What are the signs that an API control program is failing in practice?
A: Common warning signs include spikes in 403 responses, bursts of schema violations, sequential ID access, repeated webhook IDs, and tokens reused across services.
Q: When do API security controls fail in practice?
A: They fail when authentication is weak, scopes are too broad, endpoints are exposed without validation, or secrets are copied into too many places to revoke quickly.
Practitioner guidance
- Define enforceable API posture policies Write policy for authentication strength, allowed exposure, versioning, and approved business usage so the control can be checked continuously rather than reviewed manually.
- Tie API governance to IAM policy Map API callers, service identities, and access boundaries to existing identity and authorization rules so machine-to-machine access is governed consistently.
- Baseline API behaviour by workflow Establish normal call sequences, volumes, and data access patterns for critical APIs so low-and-slow abuse can be distinguished from legitimate service traffic.
Bottom line: API security now breaks when organisations mistake visibility for governance, because inventory does not enforce policy.
Glossary terms: API posture governance, API sprawl, Low And Slow API Attack, Machine-to-Machine Access
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 1:22 pm
API governance is now an authorization problem, not an inventory problem. The central failure in many API security programmes is assuming that knowing an API exists means the organisation understands what it is allowed to do. In reality, exposure, behaviour, and policy drift evolve faster than periodic review cycles. Practitioners should treat API policy enforcement as a live control plane, not a compliance afterthought.
A question worth separating out:
Q: How should organisations govern APIs that expose sensitive data?
A: They should treat those APIs as controlled access surfaces, not just technical endpoints. That means defining policy for exposure, authentication, and acceptable behaviour, then verifying that runtime activity stays within those bounds. Governance should align to the business value of the data and the identities allowed to reach it.
👉 Read our full editorial: API security governance is shifting from visibility to policy enforcement