Notifications
Clear all
Topic starter
02/08/2026 11:32 am
TL;DR: APIs expose authentication, authorization, and data-access paths that attackers can turn into breach entry points, as illustrated by MOVEit and other high-profile incidents, according to OXSecurity. The governance challenge is no longer just testing code for flaws, but controlling how API access, secrets, and third-party integrations expand risk across the software supply chain.
NHIMG editorial — based on content published by OXSecurity: API security testing and the risks of vulnerable APIs
By the numbers:
- The MOVEit data breach impacted more than 2,500 organizations and over 67 million people worldwide.
- Researchers were able to identify 1,567 breach notifications related to MOVEit.
- T-Mobile: Personal data of 37 million customers was scraped by attackers exploiting an API vulnerability in 2023.
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 turn secrets into a governance problem?
A: Because API keys, tokens, and certificates are credentials that can outlive the systems and people that created them.
Q: How do security teams know whether API rate limiting is working?
A: Look for reduced scraping, fewer bursts of automated calls, and fewer large exports from endpoints that should only support ordinary business use.
Practitioner guidance
- Map every sensitive API to an identity owner Assign a named owner for each API, then record which human, service, or third-party identities can call it and what business objects they can reach.
- Test object-level authorisation separately from authentication Build test cases for BOLA, mass assignment, and function-level access so you verify that authenticated callers still cannot overreach their intended scope.
- Treat API keys and tokens as managed NHI credentials Store them in controlled secret systems, rotate them on a defined schedule, and revoke them when integrations are retired or vendors are offboarded.
What's in the full article
OXSecurity's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of API security testing methods, including SAST, DAST, and SCA in the SDLC.
- Specific API vulnerability categories such as BOLA, SSRF, and unrestricted resource consumption in more depth.
- Comparisons between REST, SOAP, and GraphQL security controls for different deployment patterns.
- The article's own framing of API security tooling, discovery, and runtime monitoring.
👉 Read OXSecurity's full guide to API security testing and breach prevention →
API security testing: what IAM and AppSec teams need to align on?
Explore further
02/08/2026 12:46 pm
API security is now an identity control problem as much as an AppSec problem. The article is right to centre authentication, authorization, and least privilege because those are identity decisions expressed through software interfaces. Where APIs are protected only by valid credentials, organisations often confuse successful authentication with safe access. That confusion is especially costly when service accounts, tokens, and third-party integrations are the real callers. Practitioners should govern APIs as identity-bearing entry points, not just as code paths.
A question worth separating out:
Q: Who is accountable when a partner API exposes customer data?
A: Accountability sits with both the API owner and the team governing the credential lifecycle. If third-party access is not scoped, monitored, and revoked when no longer needed, the organisation has accepted standing trust without lifecycle control. Frameworks such as NIST CSF and zero trust place that responsibility on access governance.
👉 Read our full editorial: API security testing is now an identity and supply chain problem
