API incidents in 2025 expose the cost of unmanaged endpoints

At a glance

What this is: This is an analysis of five major 2025 API incidents and exposures, with the key finding that unmanaged, deprecated, and poorly authorised endpoints created the largest security gaps.

Why it matters: It matters to IAM and NHI practitioners because API exposure often becomes identity exposure, especially where tokens, session data, service credentials, and third-party access are involved.

By the numbers:

• On average, organisations test only 38% of their APIs for vulnerabilities, leaving large parts of the attack surface outside routine assurance.

👉 Read Equixly’s analysis of the five 2025 API incidents

Context

API security failures are rarely about one exotic exploit. They usually come from stale endpoints, broken authorization, and data flows that were never designed for direct adversarial access. In identity terms, the problem is that API trust often persists long after the original business context has changed, which is exactly why NHI, secrets, and access governance must extend into API lifecycle management.

Equixly’s review of five 2025 incidents shows the same control gaps appearing across payments, hiring platforms, internal enterprise systems, connected vehicles, and cloud identity endpoints. The recurring pattern is atypical only in scale, not in structure: each case began with an endpoint that was either forgotten, under-protected, or trusted more than it should have been.

Key questions

Q: What breaks when legacy APIs are left online after they are no longer needed?

A: Legacy APIs usually break security first, not functionality. They often keep weak authentication, inconsistent monitoring, and outdated business logic even after the primary platform has moved on. That creates a hidden path for attackers to validate cards, enumerate records, or reach backend systems without triggering the controls used for current services.

Q: Why do exposed APIs so often lead to identity and data compromise?

A: Because APIs frequently return identity records, session material, and role data directly to the caller. If authorization is weak or responses are too verbose, a single valid request can expose records the attacker should never see. That is why API governance and identity controls need to be reviewed together.

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. If valid credentials can still retrieve excessive data, call restricted methods, or chain privileged actions, the policy is not holding.

Q: Who is accountable when an API exposes regulated data?

A: Accountability usually sits with the business owner, security owner, and operational owner together. For regulated environments, teams need clear assignment for inventory, change approval, incident escalation, and evidence retention. If no one owns the API lifecycle end to end, compliance and response both degrade quickly.

Technical breakdown

Why legacy and shadow APIs become attack paths

Legacy APIs and shadow APIs are endpoints that remain live after the business process around them has changed, often without the controls applied to current services. They are dangerous because they sit outside normal inventory, monitoring, and test coverage. Once an attacker finds a forgotten endpoint, they often inherit whatever weak authentication, loose rate limits, or brittle business logic was left behind. In practice, these APIs behave like technical debt with an exploit surface attached. When they connect to payment, HR, or identity workflows, the impact is no longer just data exposure but downstream fraud or privilege abuse.

Practical implication: inventory, classify, and retire legacy endpoints with the same rigor used for privileged accounts and exposed secrets.

How broken authorization turns a valid login into data leakage

Broken Object Level Authorization, or BOLA, happens when an API checks that a caller is authenticated but fails to verify whether that caller is entitled to the specific object being requested. This is one of the most common ways API incidents escalate from a single account or test credential into broad data exposure. The attacker does not need to break the login system itself. They only need to manipulate object IDs, request parameters, or routing logic until the API returns records it should have withheld. This is especially risky in systems that expose employee, applicant, or customer data through predictable identifiers.

Practical implication: enforce object-level authorization on every request path, including internal, partner, and admin-facing APIs.

Why exposed identity tokens and session data amplify API incidents

API incidents become much more damaging when the response payload includes session tokens, credentials, role data, or backend metadata. Excessive data exposure means the API returns more than the client needs, often because developers assume the front end will hide sensitive fields. That assumption fails the moment an attacker talks directly to the API. In identity-heavy systems, a single leaked token or admin credential can create a wider compromise than the original endpoint flaw suggests. This is why API security, secrets governance, and identity lifecycle controls belong in one control model rather than separate reviews.

Practical implication: mask sensitive fields by default and treat any token-bearing API response as a secrets exposure candidate.

Threat narrative

Attacker objective: The attacker wants to turn one overlooked API path into broad access to data, tokens, or backend systems that should never have been reachable.

1. Entry occurs through a forgotten, deprecated, or partner-exposed API endpoint that was never fully removed from production use.
2. Escalation follows when the endpoint accepts weak authentication, predictable object identifiers, or overly broad session material that can be abused directly.
3. Impact is data exposure, account compromise, fraud enablement, or downstream access to internal systems and sensitive identity records.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API governance is now an identity problem as much as an application problem. The article shows that exposed endpoints routinely carry credentials, session tokens, role data, and personal records. That means API assurance cannot sit only with developers or AppSec, because unmanaged API behaviour can directly undermine IAM, PAM, and NHI controls. Practitioners should treat API inventory and authorization as part of identity governance, not as an isolated technical review.

Shadow API exposure is the clearest named failure mode in this set. Shadow API exposure: a live endpoint that remains reachable without adequate ownership, testing, or monitoring after its original purpose has faded. The Stripe case is the best example, but the same pattern appears wherever partner portals, internal APIs, or deprecated routes stay online. The practitioner conclusion is simple: if you cannot inventory it, you cannot govern it.

BOLA is the governance gap that most often converts access into loss. Broken Object Level Authorization is not merely a coding defect. It is an assumption failure that says authenticated access is enough, even when the caller should not see that specific record. In API-heavy identity ecosystems, that is the point at which valid access becomes unauthorised data reach. Teams should make object-level authorization a first-order control requirement in API risk reviews.

Excessive data exposure turns one API flaw into an identity breach multiplier. When responses include tokens, metadata, or unmasked personal fields, the endpoint stops being a simple application issue and becomes a control-plane exposure. That matters for identity programmes because the same records that help an API function can also help an adversary move into adjacent systems. The practitioner takeaway is to treat response minimisation as a governance control, not a cosmetic hardening step.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• From our research: Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, showing how quickly one identity failure can compound, according to The 2024 ESG Report: Managing Non-Human Identities.
• From our research: For deeper breach-pattern context, 52 NHI Breaches Analysis shows how identity and access failures recur across real-world incidents.

What this signals

Identity teams should expect API assurance to become a routine part of NHI and secrets governance. As more applications expose machine-readable interfaces, the boundary between application security and identity security keeps narrowing. The practical shift is toward continuous endpoint discovery, response minimisation, and object-level authorization checks that are tied to account and token lifecycle controls, not separate review cycles.

API exposure now creates a measurable control gap across account, token, and vendor lifecycles. That is why teams should align API reviews with the OWASP Non-Human Identity Top 10 and with internal offboarding, rotation, and entitlement review processes. The next failure is unlikely to be a single dramatic exploit. It will more often be a quiet endpoint that stayed reachable after the business moved on.

For practitioners

• Build a complete API inventory Map all production, partner, deprecated, and undocumented endpoints, then assign ownership and retirement dates for anything that no longer has a business justification.
• Test object-level authorization on every sensitive endpoint Validate that changing an object ID, account ID, or tenant reference never returns data outside the caller’s entitlement, including in test and admin flows.
• Minimise response payloads and mask identity data Remove session tokens, backend metadata, and unneeded personal fields from API responses, and verify that direct API calls cannot recover them.
• Fold API exposure into secrets and identity reviews Treat exposed credentials, bearer tokens, and service accounts as part of the same lifecycle review used for NHI and privileged access governance.

Key takeaways

• The central lesson is that API incidents are usually governance failures first and technical exploits second.
• Equixly’s review shows that forgotten endpoints, weak authorization, and verbose responses can expose both data and identity material at scale.
• Security teams should govern APIs as part of identity, secrets, and lifecycle controls, not as a standalone engineering concern.

Key terms

• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• 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.
• Excessive Data Exposure: Excessive data exposure occurs when an API returns more information than the caller actually needs. The issue is usually a design and authorization problem rather than a coding typo, and it increases breach impact because a stolen credential can reveal far more data than intended.
• API Lifecycle Management: API lifecycle management is the practice of governing APIs from creation through versioning, change, retirement, and revocation. For security teams, the important part is tying identity controls to each phase so credentials, permissions, and integrations do not outlive the service they support. That keeps machine access from becoming permanent by default.

What's in the full article

Equixly's full blog research covers the operational detail this post intentionally leaves for the source:

• Step-by-step attack breakdowns for each of the five incidents, including request flows and response behaviour.
• Specific API flaws and proof points behind the Stripe, McDonald’s / Paradox.ai, Intel, Volkswagen, and Azure AD cases.
• The researchers’ observations on how each flaw could be tested or validated in practice.
• The article’s concluding remediation framing for teams that need to prioritise API discovery and testing.

👉 Equixly’s full post covers the five attack chains, exposure paths, and remediation lessons in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and identity lifecycle control. It gives practitioners a structured way to connect identity risk to broader security programmes.