Notifications
Clear all
Topic starter
02/08/2026 11:32 am
TL;DR: 95% of organisations experienced an API security incident, with BOLA, broken authentication, SSRF, inventory gaps, and unsafe consumption driving abuse across modern applications, according to Salt Security. The core issue is not just vulnerable endpoints, but missing governance over API access, business logic, and shadow inventory.
NHIMG editorial — based on content published by Salt: OWASP API Security Top 10 and the evolving API attack landscape
By the numbers:
- 95% of organizations experienced some form of API security incident.
- Broken object level authorization is represented in about 40% of all API attacks.
Questions worth separating out
Q: How should security teams implement function-level authorization in APIs?
A: Security teams should enforce authorization on the server side for every sensitive function, not just at the UI or gateway layer.
Q: Why do API keys and tokens need non-human identity governance?
A: Because they behave like access-bearing identities, not static configuration values.
Q: What breaks when organisations do not maintain a complete API inventory?
A: Unknown and stale endpoints stay reachable, which means security controls, logging, and retirement processes miss part of the attack surface.
Practitioner guidance
- Enforce object-level authorization everywhere Require every API request to re-check object entitlement against caller context, role, and policy rather than trusting session success alone.
- Treat API credentials as managed identities Inventory API keys, bearer tokens, and service credentials as non-human identities with owners, scopes, rotation rules, and expiry dates.
- Build a live API inventory Continuously discover endpoints, map versions, and flag unmanaged or deprecated APIs that still accept traffic or credentials.
What's in the full article
Salt's full article covers the OWASP API Security Top 10 detail this post intentionally leaves for the source:
- Walkthrough of all ten OWASP API risks, including how each category changes implementation priorities.
- Salt's framing of discovery, posture governance, and runtime threat protection for API environments.
- Practical examples of how BOLA, BFLA, SSRF, and unsafe consumption show up in real application stacks.
- The source article's own summary of why API security needs both development and security ownership.
👉 Read Salt's analysis of the OWASP API Security Top 10 and API attack patterns →
OWASP API security risks: are your access controls keeping up?
Explore further
02/08/2026 12:47 pm
BOLA is an authorization failure, not an authentication failure. The industry often over-focuses on login strength, while the real weakness sits in object-level policy enforcement. APIs can authenticate a caller correctly and still leak records if the service does not verify per-object entitlement. For identity teams, this is a reminder that access control has to extend into the application layer, not stop at the token boundary.
A question worth separating out:
Q: How do teams reduce abuse without slowing legitimate API traffic?
A: Use rate limits, quotas, and throttling differently for authentication, read, and write operations. Then combine those controls with logging and alerting so you can distinguish normal bursts from brute force or scraping. The goal is not just to block volume, but to make abuse visible and containable.
👉 Read our full editorial: OWASP API security risks expose gaps in access and inventory
