API security incidents exposed identity and access gaps in 2022

At a glance

What this is: This is an independent analysis of 2022 API security incidents, with the key finding that exposed or poorly governed APIs enabled large-scale personal data compromise.

Why it matters: It matters because APIs increasingly sit on the boundary between application security and identity governance, so weak authentication, authorisation, and test-network exposure can undermine both human identity and NHI controls.

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.
• Optus faced claims involving up to 11.2 million sensitive customer records after an API for a customer identity database was exposed to a test network with internet access.
• T-Mobile said personal information from 37 million postpaid and prepaid customer accounts was stolen through an exposed API.

👉 Read Pynt's analysis of 2022 API security incidents and identity exposure

Context

API security failures are rarely just application bugs. They usually reflect governance gaps around authentication, authorisation, exposure boundaries, and the handling of identity-linked data. In this article's topic area, those weaknesses can also affect NHI controls when APIs are used by service accounts, integrations, and automation workflows.

The 2022 incidents cited here show a common pattern: public-facing interfaces, test environments, and identity databases were treated as lower-risk than they were. That assumption is typical across large enterprises, especially where development velocity outpaces security review and API inventory discipline.

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 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. Attackers usually target the secret, not the endpoint. Once they have a valid key or token, they can impersonate the workload and inherit whatever access that identity already has.

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. If the control is effective, suspicious traffic should be slowed, challenged, or blocked before it reaches core systems, while legitimate integrations continue to function normally.

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.

Technical breakdown

How API authentication failures expand attack surface

APIs often rely on tokens, keys, session assertions, or client credentials to establish trust, but the trust decision is only as strong as the control around issuance, validation, and scope. When authentication is weak, bypassed, or inconsistently enforced across versions and environments, an attacker may enumerate identities, call sensitive endpoints, or pivot from one valid token to broader access. This is especially dangerous when APIs expose customer identity data or act as gateways to internal systems. For identity teams, API authentication is not a narrow application concern, because it determines whether access decisions remain tied to the intended subject and purpose.

Practical implication: enforce uniform API authentication policy across all environments and audit token scope against actual endpoint exposure.

Why authorisation and object-level access control fail in APIs

APIs can pass authentication while still failing authorisation if they do not validate which object, record, or tenant the caller is allowed to access. This is where broken object-level authorisation, overly broad query parameters, and weak context checks become breach enablers. In practice, an attacker does not need to break the whole system if the API will return data tied to another account after a valid request. For IAM practitioners, the lesson is direct: access control must be enforced at the resource level, not just at the login or token level, otherwise identity data becomes broadly retrievable.

Practical implication: test object-level authorisation on every sensitive endpoint, especially those returning identity or customer records.

Why test networks and exposed environments create hidden identity risk

The Optus case illustrates a frequent control failure: non-production environments are sometimes connected to networks that are more reachable than intended. If a test network can reach production-like identity stores or API back ends, the environment boundary is no longer meaningful. That breaks the assumption that testing infrastructure is isolated from sensitive data, and it creates a path from development convenience to production compromise. In identity terms, this can expose customer identity databases, service credentials, and downstream integrations in one move. The issue is not testing itself, but the absence of strict network segmentation and environment-specific access policy.

Practical implication: isolate test networks from production identity systems and verify that non-production access paths cannot reach sensitive APIs.

Threat narrative

Attacker objective: The attacker aims to turn exposed API access into large-scale identity and customer data theft that can be monetised or used for extortion.

1. Entry begins when an attacker finds an exposed or weakly protected API endpoint, or a test environment connected to an internet-reachable network.
2. Escalation occurs when the API accepts over-broad requests, weak token validation, or insufficient object-level checks that let the attacker enumerate or retrieve data outside the intended boundary.
3. Impact follows when identity data, customer records, or account-linked information is exfiltrated and then sold, extorted, or used for follow-on fraud.

NHI Mgmt Group analysis

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.

Broken object-level authorisation is the most operationally dangerous API failure mode. An API can authenticate a caller correctly and still leak another user's or tenant's data if resource checks are missing. This is why endpoint testing must include identity-centric abuse cases, not just generic scanning. The governance lesson is simple: prove that access decisions are enforced on the object being requested, not merely on the session that makes the request.

Test-environment exposure creates a hidden bridge from development risk to production identity compromise. The Optus example shows how a network boundary can collapse when a test system is allowed to reach live or identity-rich back ends. That failure mode is not unusual in large programmes, especially where delivery teams optimise for speed over isolation. The named concept here is environment boundary collapse: once non-production can reach sensitive identity data, the separation assumption no longer holds.

API incidents validate the need for lifecycle control over credentials and service access. APIs are often exercised by service accounts, integrations, and automation paths that are invisible to manual review. If those identities are not inventoried, scoped, and periodically recertified, attackers inherit a trust path that defenders have not fully governed. Practitioners should fold API access into the same lifecycle discipline used for human access and NHI controls.

What this signals

API programmes are increasingly part of identity governance whether teams label them that way or not. Where tokens, service accounts, and customer identity endpoints sit behind the same interface layer, access review, least privilege, and environment separation need to be measured together rather than managed in silos.

Environment boundary collapse: when test systems can reach identity-rich production back ends, the control plane is effectively shared. That is a governance problem as much as a network problem, and it calls for stricter segmentation, stronger API discovery, and routine validation that non-production cannot touch sensitive identity stores.

Practitioners should expect API security reviews to become more identity-aware as regulators and customers demand proof that access is limited, logged, and explainable. The useful question is no longer whether the API works, but whether it can prove who or what is allowed to use it.

For practitioners

• 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.
• Bring API tokens into NHI governance Treat API keys, bearer tokens, and service credentials as governed NHI artefacts with ownership, expiry, rotation, and revocation controls.

Key takeaways

• API incidents in 2022 showed that exposed interfaces can become identity breaches when authentication, authorisation, and environment boundaries are weak.
• The evidence is large-scale and repeatable, with incidents affecting millions of accounts and an analyst-reported 257% surge in API attacks against financial services.
• Practitioners should govern APIs as part of identity security, especially where service credentials, customer records, and test networks intersect.

Key terms

• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• API Trust Boundary: An API trust boundary is the point at which a system decides whether to accept, reject, or constrain a request based on identity, policy, and context. It is where authentication becomes governance, because the boundary determines what data can move and under what conditions.
• Identity Data Gateway: An identity data gateway is an API or service layer that mediates access to accounts, profiles, and other identity-linked records. Because it sits between users or systems and sensitive identity data, its authentication, authorisation, and logging controls directly influence breach blast radius.

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

👉 Pynt's full article covers the Twitter, Optus, and T-Mobile cases in more detail, including the exposure paths and business impact.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps security practitioners connect access control, lifecycle discipline, and identity risk across human and non-human programmes.