Topic starter
02/08/2026 12:19 pm
TL;DR: APIs increasingly carry sensitive data across customer apps, partners, and microservices, but signature-based controls miss the subtle abuse patterns attackers now favour, according to Salt. The practical lesson is that API security has become a governance problem as much as a detection problem, because authentication, authorization, and behavioural visibility must work together.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “How to Control Top API Security Risks”.
Key questions
Q: What breaks when API authentication is correct but authorisation is weak?
A: Attackers can still read or modify data they should not reach, because identity was proven without proving entitlement.
Q: Why do valid API requests still create breach risk?
A: Valid API requests still create breach risk because authentication proves the caller is known, not that the caller is entitled to the specific object.
Q: How can security teams tell whether API risk controls are actually working?
A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why.
Practitioner guidance
- Tighten API authentication assurance Require stronger enrolment, anti-replay protections, and credential hygiene for public and partner-facing APIs so a valid login does not become the only trust signal.
- Map authorisation to API objects and functions Document which identity types may call each sensitive endpoint, then test that object-level and function-level permissions match the intended business flow.
- Add behavioural detection for API misuse Monitor request sequences, call volume, and abnormal identity context so low-and-slow abuse can be detected even when each individual call looks legitimate.
Bottom line: API security fails when organisations treat authentication as sufficient and do not govern specific API actions.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:20 pm
API security is now an identity governance problem, not just an application security problem. Once APIs become the primary route between users, partners, and microservices, the question shifts from whether a request is authenticated to whether the caller should be allowed to perform that exact action. That brings IAM and API governance together, because access decisions now need to follow identity, context, and function. Practitioners should treat API authorisation as a governed access model, not an afterthought to login control.
A few things that frame the scale:
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: What should security teams prioritise first in API security governance?
A: Start with the endpoints that expose sensitive data, privileged actions, or partner integrations, because those functions create the greatest breach and business impact if authorisation fails. Then layer behavioural monitoring so legitimate credentials cannot hide malicious call patterns.
👉 Read our full editorial: API security fails when authentication and authorization go granular