API incidents in 2025 expose the cost of unmanaged endpoints

At a glance

What this is: This is Equixly’s analysis of five API incidents in 2025, showing that unmanaged endpoints and weak authorization created repeated paths to data exposure, fraud, and partner risk.

Why it matters: It matters because API governance now sits at the junction of application security, secrets management, and identity control, especially where external services and exposed data objects are involved.

By the numbers:

• On average, organizations test only 38% of their APIs for vulnerabilities, leaving legacy and shadow APIs dangerously exposed.
• The McDonald’s / Paradox.ai incident exposed the personal information of approximately 64 million applicants.

Context

API incidents are rarely just coding mistakes. They are governance failures in endpoint inventory, authorization boundaries, and lifecycle management, especially when APIs expose identities, personal data, or privileged backend functions.

In this article, Equixly treats API security as an operational control problem rather than a narrow engineering issue. That framing matters for IAM, because many of the failures described here depend on broken authentication, overbroad object access, stale endpoints, or third-party flows that were never governed as part of the access model.

Key questions

Q: What breaks when a public API is left outside the official inventory?

A: The control chain breaks at discovery, testing, and monitoring. An unmanaged endpoint may still reach backend systems but sit outside normal assurance, which means weaker authentication, slower remediation, and less logging. In practice, that creates a shadow path for data exposure, fraud, or token abuse even when the main application appears well governed.

Q: Why do broken object-level authorization flaws create large-scale data exposure?

A: Because the API confirms the caller is signed in but fails to confirm the caller is allowed to access the specific object. When records use sequential IDs or predictable parameters, attackers can swap values and enumerate data at scale. The result is not just a technical bug but a failure of entitlement enforcement at the object layer.

Q: What do teams get wrong about protecting internal APIs?

A: Teams often assume internal APIs are safe because they sit behind a restricted network or use relaxed authentication and authorization. That assumption breaks when external attack chains reach internal services, when internal calls are abused, or when an internal API is unintentionally exposed. Internal APIs need the same discovery and runtime controls as external ones.

Q: How should organisations govern personal data flows across APIs under privacy law?

A: They should map every API that carries personal information, assign an accountable owner, and enforce disclosure, retention, and purpose limits at runtime. A privacy policy alone is not enough. Teams need lineage, logging, and control points that show where data moved, who could access it, and whether the transfer was lawful.

Technical breakdown

Why shadow and zombie APIs expand the attack surface

Shadow APIs are endpoints that were never properly inventoried, while zombie APIs are deprecated interfaces that remain reachable after they should have been retired. Both fail because security tooling, testing, and monitoring usually follow the official application map, not the full runtime reality. That gap is dangerous when old endpoints still connect to backend validation, identity, or data services. If attackers can reach them, they often inherit weaker authentication, missing logging, and inconsistent rate controls that modern endpoints no longer allow.

Practical implication: Treat API discovery and decommissioning as a control requirement, not a cleanup task.

How broken object-level authorization turns valid access into data theft

Broken object-level authorization, or BOLA, occurs when the API checks that a caller is authenticated but fails to verify whether that caller may access the specific object requested. This is especially common when sequential IDs, predictable parameters, or tenant records can be swapped in requests. From an IAM perspective, the failure is not only authentication but entitlement enforcement at the object layer. A valid session or account can still become an authorization bypass if the API trusts the caller too much once login has succeeded.

Practical implication: Enforce object-level authorization checks on every request that returns user, tenant, or transaction data.

Why exposed internal APIs become identity risks

Internal APIs often assume a trusted environment, but once they are exposed through partner portals, browser-accessible code, or misconfiguration, that trust assumption collapses. These endpoints can leak session tokens, role data, personal information, or backend credentials if response filtering and authentication are weak. The identity angle is direct: when APIs expose privileged tokens or data objects, they extend access beyond intended identity boundaries and undermine zero-trust assumptions. That makes undocumented APIs a governance problem, not just a development defect.

Practical implication: Inventory internal APIs separately from external ones and apply the same access, logging, and review standards to both.

Threat narrative

Attacker objective: The objective is to turn reachable API logic into unauthorized access to data, tokens, or payment flows that can be monetized, abused, or further chained.

1. Entry occurred through exposed or poorly governed API surfaces, including legacy endpoints, third-party portals, and client-side calls that attackers or researchers could reach.
2. Credential or authorization abuse followed when weak authentication, default credentials, or missing object-level checks allowed valid sessions to access data they should not have seen.
3. Escalation and collection happened as attackers or researchers enumerated objects, retrieved sensitive records, and in some cases exposed tokens or backend credentials.
4. Impact included merchant skimming, applicant data exposure, employee and supplier data leakage, and broader trust damage across customer and partner ecosystems.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 governance is now an access-control discipline, not just an engineering hygiene exercise. The incidents in this article show that authentication alone does not contain risk when object-level authorization, endpoint inventory, and decommissioning are weak. Once a legacy or undocumented endpoint is reachable, the access model itself becomes the security boundary. Practitioners should treat APIs as governed access paths, not passive integration plumbing.

Shadow and zombie APIs create a governance blind spot that identity teams should care about. The article’s cases show that endpoints outside the official inventory are the ones least likely to receive the same testing, logging, and review as known services. That creates a parallel access layer where data and tokens can move without normal assurance controls. The practical conclusion is that endpoint discovery belongs alongside lifecycle management and entitlement review.

BOLA is the API equivalent of over-permissioned access, and it is often the real failure mode. The McDonald’s and Intel examples show that a valid login can still be a dangerous identity if the API does not verify what the caller is entitled to see. This is why object-level authorization should be treated as part of the access decision, not a secondary validation step. Teams that separate authentication from entitlement too cleanly leave a gap attackers can exploit.

Third-party APIs now sit inside the enterprise trust boundary whether teams admit it or not. The Paradox.ai incident shows that supplier APIs can expose customer data even when the primary brand is not the operator of the flawed system. That makes vendor assurance continuous, not one-time, and it places API security in the same governance conversation as supplier access, lifecycle offboarding, and data minimisation. Practitioners should re-evaluate how much trust they extend to partner-managed endpoints.

Unmanaged endpoints are a form of identity debt. They accumulate when old interfaces, internal functions, and client-side assumptions remain active after the original trust model has changed. Over time, that debt shows up as exposed data, insecure authentication, or credentials leaking through API responses. Teams should recognise unmanaged endpoints as a structural control gap, not an isolated incident class.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Unmanaged endpoints are identity debt. They persist when teams deprecate interfaces in code but not in governance, and the result is an access surface that no one is actively certifying. That pattern is especially dangerous where APIs return personal data, session material, or backend tokens, because the control failure is entitlement drift rather than simple vulnerability exposure.

The next phase for practitioners is to connect API discovery, authorization testing, and supplier assurance into one access model. If a partner-managed endpoint can expose data objects or if a legacy route still validates transactions, the issue belongs in IAM and lifecycle governance as much as in application security.

For practitioners

• Implement continuous API inventory Map every production, partner, and legacy endpoint to an owner, authentication method, and retirement date, then remove or quarantine anything that is no longer in service.
• Enforce object-level authorization on every request Validate that the authenticated caller is entitled to the specific object, record, or tenant before returning data, especially where sequential IDs or predictable parameters exist.
• Harden third-party API assurance Require pre-production validation and ongoing reassessment for vendor-managed endpoints that handle applicant, customer, or employee data, with particular attention to BOLA and data exposure.
• Retire zombie endpoints deliberately Track deprecated APIs through formal decommissioning, revoke any hidden backend dependencies, and verify that old routes are no longer reachable after release cycles.
• Review client-side code for hidden API exposure Treat any endpoint referenced in browser scripts as public unless proven otherwise, and remove sensitive data or tokens from responses that the client could intercept.

Key takeaways

• Unmanaged APIs become attack paths when inventory, retirement, and monitoring fall out of sync with application change.
• The incidents in this article show that valid authentication does not protect data when object-level authorization is weak or missing.
• For practitioners, the control answer is continuous endpoint discovery, entitlement enforcement, and continuous assurance of third-party APIs.

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.
• Zombie API: A zombie API is a deprecated or abandoned interface that remains accessible after the organisation believes it should be retired. It is risky because old permissions, secrets, or backend trust can survive the business purpose, turning legacy access into an active exposure.
• 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.
• Third-Party Api Risk: Third-party API risk is the exposure created when a vendor-controlled endpoint processes your data or supports your workflows. The customer does not own the code, but still inherits the business and regulatory impact if authentication, authorization, or response handling fails.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programmes they run across cloud, applications, and partners.