Notifications
Clear all
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.
NHIMG editorial — based on content published by Salt: API Security Strategy and Top API Security Risks
By the numbers:
- That fine could reach $1.63B GDPR fine for Facebook.
Questions worth separating out
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 APIs create identity governance risk across machine and human access?
A: APIs often carry the real access decision for service accounts, tokens, and human sessions.
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
- Inventory API identities and entitlements Map which users, service accounts, and partner integrations can call each sensitive API action.
- Test authorisation against real business actions Validate whether authenticated identities can only perform the actions they are meant to perform, especially in chained workflows and microservices.
- Deploy API behavioural monitoring Baseline normal request patterns and alert on deviations such as unusual data access sequences, low-and-slow enumeration, or repeated probing of edge-case logic.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- Examples of how attackers use valid credentials to probe APIs without triggering obvious alarms.
- Practical discussion of how authentication, authorisation, rate limiting, and shift-left measures fit together in an API stack.
- Specific commentary on why nuanced API behaviour is difficult for traditional WAF and RASP tools to interpret.
- The source article's threat framing around data exfiltration and denial-of-service scenarios in API-heavy environments.
👉 Read Salt's analysis of API security strategy and modern attack paths →
API security gaps: are your controls keeping up with modern attacks?
Explore further
02/08/2026 1:20 pm
API security has become an identity governance problem, not just a web protection problem. The article shows that attackers are not only looking for code flaws, they are looking for usable identities and permissions that let them operate through valid API calls. That is why API authorisation now sits alongside IAM governance, because the question is not simply whether a request is authenticated, but whether the calling identity should be trusted for that action. Practitioners should treat API entitlements as governed access, not as implementation detail.
A question worth separating out:
Q: Who is accountable when a public API leaks data through valid access?
A: Accountability usually spans application owners, IAM or platform teams, and security leadership, because the failure is shared between access design, endpoint logic, and monitoring. In regulated environments, the organisation must also be able to show that access controls and logging were proportionate to the sensitivity of the data involved.
👉 Read our full editorial: API security fails when authentication and authorization go granular
