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.
At a glance
What this is: This look-back on 2022 API security incidents argues that exposed APIs, weak authentication and mis-scoped test environments turned identity data into breach fuel.
Why it matters: It matters because API security now sits directly inside IAM and identity governance, where authentication, authorisation and environment isolation determine how far an incident can spread.
By the numbers:
- Akamai reported a 257% increase in web application and API attacks on financial service institutions in 2022.
Context
APIs are not just application plumbing. They are control points that decide who or what can reach sensitive data, so failures in authentication, authorisation or test-environment isolation quickly become identity governance problems rather than narrow application bugs.
The 2022 incidents in this article are typical of a broader pattern: when API access is treated as a development detail instead of a governed access path, customer records, account lookups and identity data become easier to enumerate, expose or exfiltrate.
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. That failure usually appears as BOLA, broken function-level access, or mass assignment. Security teams should test whether an authenticated caller can move from one object, record, or action to another without additional approval.
Q: Why do exposed API keys and weak API controls create outsized breach risk?
A: Exposed API keys are powerful because they often grant direct access to applications, data, and automation paths without the friction of interactive login. If keys are reused, overprivileged, or poorly monitored, a single leak can enable broad unauthorized access and rapid abuse. API controls matter because digital services increasingly depend on machine-to-machine access that attackers can exploit quietly.
Q: What do security teams get wrong about test environments and APIs?
A: Teams often assume test networks are harmless because they are not customer-facing. In practice, if a test environment can reach live APIs or production data, it inherits production-level risk without the same controls, monitoring or approval. The mistake is treating environment labels as a control instead of enforcing real network and data separation.
Q: How should IAM teams govern APIs that expose personal data?
A: Treat those APIs as access pathways into identity data, not as simple integration points. IAM teams should define who or what can call them, what attributes may be returned, and whether the response reveals account existence or ownership. Governance has to cover authentication, authorisation, logging and response minimisation together.
Technical breakdown
Why API authentication failures become identity incidents
API authentication is the proof mechanism that binds a request to an identity, whether that identity is a customer, a service account or another system. When the API accepts weak, missing or improperly scoped authentication, attackers can query account state, enumerate users or pivot from one identifier to another. In IAM terms, the problem is not just access, but how access is asserted and validated at the API boundary. API endpoints that reveal identity-linked data without strong verification turn low-friction lookups into breach primitives.
Practical implication: treat API authentication and request binding as identity controls, not only application controls.
How exposed test environments widen the blast radius
A test environment connected to an API may be intended for internal validation, but if it has internet reachability it becomes an unexpected production-like exposure path. The risk is not the test environment itself, but the failure to separate trust zones and data paths. Once a test network can reach a customer identity database or production API, controls around segmentation, access scope and environment isolation have already broken down. This is a classic governance failure because temporary systems inherit real data access without matching oversight.
Practical implication: isolate test access from production identity data and verify that non-production networks cannot reach live APIs.
Why exposed APIs turn sensitive data into breach fuel
An exposed API often gives attackers a structured way to query, correlate and extract personal data at scale. That makes API security an identity problem as well as a data problem, because the same interface that authenticates users may also reveal whether a phone number or email address maps to an account. Once that mapping exists, attackers can support phishing, account takeover or downstream fraud. The issue is not only confidentiality, but the conversion of identity data into reusable attack material.
Practical implication: inventory API endpoints that expose identity-linked fields and reduce the data returned by unauthenticated or low-trust queries.
Threat narrative
Attacker objective: The attacker objective was to harvest and monetise customer identity data at scale by abusing weak API access paths.
- Entry occurred through an API vulnerability that allowed attackers to submit email addresses or phone numbers and learn which account they matched.
- Escalation followed when attackers used exposed API access or an internet-reachable test environment to obtain larger volumes of customer identity data.
- Impact was the sale or theft of millions of records, creating breach exposure, extortion risk and downstream misuse of personal information.
Breaches seen in the wild
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
API security is now an identity governance problem, not a pure application problem. The article's incidents show that authentication and authorisation decisions at the API layer directly determine whether identity data can be enumerated or extracted. That puts API governance alongside IAM, because the API often becomes the practical enforcement point for who or what may touch account data.
Environment isolation is the overlooked control that changes API blast radius. The Optus example shows how a test network with internet access can become a live exposure path when it reaches real identity data. That is a governance failure in access boundary design, and it should be treated as part of identity and data control review, not only network hygiene.
Queryable identity data is breach fuel. APIs that reveal account relationships, customer records or lookup results can hand attackers the raw material for phishing, account takeover and fraud. The named concept here is identity lookup exposure: when an API turns a simple query into a scalable path from identifier to personal data. Practitioners should reduce that surface before attackers operationalise it.
2022 was a signal year for API-driven identity exposure. The incidents in this article show that exposure is rarely one control failure. It is a stack of weak authentication, broad access scope and insufficient separation between environments. That combination is now common enough that teams should review APIs as part of identity risk management, not as isolated development assets.
From our research library:
- Organisations that rely heavily on static credentials reported a 20-percentage-point increase in security incidents compared with those with low reliance, according to the 2026 Infrastructure Identity Survey.
- Read next: NHI Authentication Guide
What this signals
Identity lookup exposure: APIs that let a requester infer account existence or ownership create a distinct governance problem because they convert simple identifiers into breach-ready intelligence. The control question is no longer only who can authenticate, but what an authenticated or unauthenticated query is allowed to reveal.
API security reviews should therefore sit alongside IAM, not below it. If authentication and response scoping are weak, the API becomes a policy bypass that can feed phishing, fraud and account takeover even when the rest of the application stack looks sound.
For practitioners
- Tighten API authentication and request binding Require strong authentication on every API that returns identity-linked data, and verify that tokens, keys or sessions are scoped to the minimum readable attributes.
- Separate test networks from production identity data Block non-production environments from reaching live customer databases or production APIs, and validate that test access cannot cross trust boundaries.
- Reduce account lookup and enumeration risk Review endpoints that let a user submit an email address, phone number or other identifier and infer account existence or ownership, then remove unnecessary responses.
- Monitor APIs for unusual identity-data access patterns Set alerts for spikes in lookup volume, repeated identifier probing, or abnormal requests against endpoints that return personal or account data.
Key takeaways
- API incidents in 2022 showed that access control failures at the interface layer can expose identity data as efficiently as a direct breach of a customer system.
- The article's examples combine authentication weakness, environment isolation failure and excessive data exposure, which is why the blast radius extends beyond the API itself.
- Teams should govern APIs as identity-bearing access paths, with tighter authentication, smaller responses and hard separation between test and production trust zones.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | The article centres on API access failures that let attackers query or steal identity data. |
| API8 — Security Misconfiguration | The Optus example points to unsafe network exposure of a test-connected API environment. | |
| API9 — Improper Inventory Management | Untracked or poorly governed APIs increase the chance of exposed identity lookup paths. | |
| Recommendation — Enforce API authentication and token scoping before exposing any identity-linked endpoint. Harden API deployment settings and block non-production networks from production data paths. Inventory all API endpoints and retire any unauthorised or forgotten identity-data surfaces. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | API authorization and response scope directly determine how much identity data can be reached. |
| Recommendation — Apply PR.AA-05 to limit API responses to the minimum identity data required. | ||
| CIS Controls v8 | CIS-5 — Account Management | The incidents rely on account and identity handling that should be tightly governed. |
| Recommendation — Use account management controls to reduce exposed identifiers and unauthorized access paths. | ||
Key terms
- API Authentication: API authentication is the process of proving that a client, service, or application is allowed to call an API. It uses credentials such as keys, tokens, certificates, or signed assertions to verify identity. Strong API authentication reduces unauthorized access, supports auditability, and is a core control for machine-to-machine trust.
- Environment Isolation: Environment isolation is the practice of keeping development, test, and production access separated so compromise in one zone does not automatically reach another. For machine identities, weak isolation usually means the same credential or trust relationship can cross boundaries and enlarge the blast radius.
- Identity Lookup Exposure: Identity lookup exposure occurs when an API reveals whether an email address, phone number or other identifier maps to an account. That seemingly small response can enable enumeration, phishing, fraud and later access abuse because it turns identity verification logic into attacker intelligence.
- Response Scoping: Response scoping is the practice of limiting what an API returns to the least amount of data required for the task. It matters because many breaches begin when an endpoint exposes more personal or account information than the caller actually needs.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. The NHI Foundation Level course, the industry's only accredited NHI security programme, is designed for practitioners who need to govern credentials, access and identity risk across modern environments.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org