Notifications
Clear all
Topic starter
19/08/2026 3:37 pm
TL;DR: API attacks surged in 2022, with Akamai reporting a 257% increase against financial services and incidents at Twitter, Optus, and T-Mobile showing how exposed interfaces can turn identity data into breach fuel, according to Pynt. For IAM and security teams, the lesson is that API security is also identity governance, because authentication, authorisation, and exposed test environments shape blast radius.
NHIMG editorial — based on content published by Pynt: API security incidents in 2022 and the identity risks they exposed
By the numbers:
- Akamai reported a 257% increase in web application and API attacks on financial services institutions in 2022 compared with the prior year.
- T-Mobile said personal information from 37 million postpaid and prepaid customer accounts was stolen through an exposed API.
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 risk even when the application code is secure?
A: APIs create identity risk because the code can be clean while the credentials behind it remain exposed, over-privileged, or reused.
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
- Inventory all externally reachable APIs Create a single list of internet-facing, partner-facing, and internally exposed APIs, then map each one to the data classes and identity systems it can touch.
- Test object-level authorisation on sensitive endpoints Run negative tests that try to access another user's record, another tenant's object, and unauthorised identity attributes through the same endpoint and token type.
- Separate test networks from production identity systems Block non-production environments from reaching production identity stores, customer databases, and privileged admin APIs, and verify the network rules with access-path testing.
What's in the full article
Pynt's full article covers the incident details and 2022 examples this post intentionally leaves at the pattern level:
- Named incident summaries for Twitter, Optus, and T-Mobile with the exploit context behind each case
- The specific API exposure patterns that let attackers identify account ownership or reach customer databases
- Why exposed test networks and internet-accessible non-production systems turn into real attack paths
- The article's own recommendations on authentication, encryption, monitoring, and secure development
👉 Read Pynt's analysis of 2022 API security incidents and identity exposure →
API security incidents in 2022: what should IAM teams watch?
Explore further
19/08/2026 4:17 pm
API security is now identity security by another name. Where APIs expose account data, identity databases, or automation interfaces, the security problem becomes access governance rather than only application hardening. That means IAM, PAM, and NHI teams should treat API inventory, token scope, and endpoint authorisation as part of the same control surface. Practitioners should align API governance with identity governance, not leave it isolated in application security.
A question worth separating out:
Q: Who is accountable when an exposed API credential is abused?
A: Accountability should sit with the service owner and the identity governance function, not just the platform team. API credentials are lifecycle assets, so control failure usually spans design, issuance, monitoring, and retirement. Frameworks like the NIST Cybersecurity Framework 2.0 help structure that ownership.
👉 Read our full editorial: API security incidents exposed identity and access gaps in 2022
