Notifications
Clear all
Topic starter
02/08/2026 12:21 pm
TL;DR: API attacks often succeed because adversaries use endpoints exactly as designed, with Salt citing 94% of API attacks against authenticated endpoints and users and a RapidAPI survey finding only 4.3% of developers tested APIs for security. Authentication alone does not govern authorization risk or runtime abuse.
NHIMG editorial — based on content published by Salt: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
Questions worth separating out
Q: What breaks when API security relies on bearer tokens alone?
A: Bearer-only API security breaks when a token can be intercepted and replayed by anyone who possesses it.
Q: Why do authenticated API endpoints still need strong authorisation controls?
A: Authenticated endpoints still need authorisation because identity proof does not equal request legitimacy.
Q: How do security teams know if API authorisation is actually working?
A: They should test whether each identity can only complete the specific actions it is supposed to perform, then compare that result with runtime logs and anomaly patterns.
Practitioner guidance
- Enforce server-side field-level authorisation Move filtering and entitlement checks into the back end so sensitive data is never returned just because a front end omitted it.
- Correlate API requests across time Build detection rules that join repeated low-risk calls, parameter changes, and response anomalies into one attack sequence.
- Test APIs with adversarial workflows Use deliberately vulnerable applications, runtime traffic review, and misuse cases to see how the API behaves when a caller chains requests or escalates from legitimate access.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- Session-level examples of how authenticated API calls are abused to expose excess data
- Practical guidance on exercising APIs in pre-production to surface logic flaws and missing response controls
- Speaker perspectives from Corey Ball and Katie Paxton-Fear on adversarial testing and runtime analysis
- The underlying survey and incident references that support the article's API security claims
👉 Read Salt's analysis of API abuse, authorization gaps, and testing blind spots →
API security and authorization gaps: what practitioners are missing?
Explore further
02/08/2026 1:22 pm
Authentication-first API governance is a control gap, not a control model. The article shows how easily organisations confuse identity verification with authorisation assurance. In API environments, a valid token or logged-in user says little about whether a request should expose a given field, object, or workflow. That makes response filtering, scope enforcement, and server-side policy the real governance layer. Practitioners should treat authenticated API traffic as untrusted until authorisation is proven at the point of data release.
A question worth separating out:
Q: Should organisations treat APIs as identity and access control points?
A: Yes. APIs increasingly carry user, service, and third-party access decisions, so they function as active identity control points. That means token scope, response minimisation, delegation, and lifecycle management all matter. If those controls are weak, the API becomes a pathway for unauthorised disclosure even when authentication is intact.
👉 Read our full editorial: API attacks exploit design assumptions, not just bad authentication
