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.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “How Thinking Like an Attacker can Improve your API Security”.
By the numbers:
- 94% of API attacks occur against authenticated endpoints and users.
Key questions
Q: What breaks when an API assumes authentication is enough for trust?
A: The trust model breaks at the authorization layer.
Q: Why do authenticated API users still create security risk?
A: Because valid credentials can still be abused.
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.
Practitioner guidance
- Harden authorization at the response layer Enforce object-level and field-level checks on every API response so authenticated callers only receive data that matches their role and business purpose.
- Minimise payloads by default Review each endpoint to remove unnecessary fields, suppress sensitive metadata such as MFA status unless required, and redesign responses around least-data principles.
- Correlate API events over time Build detection logic for repeated probes, shifting request patterns, and low-and-slow abuse that only becomes visible across multiple calls.
Bottom line: API attacks frequently succeed because the endpoint works exactly as designed, which leaves authorization and data minimisation as the real control points.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:22 pm
Authentication is not an authorization model: once a caller is inside an API, the security question becomes what data and actions that identity can actually justify. The article’s core warning is that many organisations still over-trust successful login or token validation as if it covered the whole risk decision. For IAM and API governance, that is a control boundary error, not a minor tuning issue. Practitioners should treat authorization and data minimisation as first-class controls, not post-authentication refinements.
A few things that frame the scale:
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
A question worth separating out:
Q: Should teams prioritise API authorization testing over authentication testing?
A: They should treat them as different controls and prioritise authorization testing whenever the business risk is data exposure or workflow abuse. Authentication proves who or what is calling. Authorization proves what that caller can do and see, which is where many API incidents actually happen. Both matter, but they fail differently.
👉 Read our full editorial: API attacks exploit design assumptions, not just bad authentication