2025 Top 5 API Incidents

Deconstructing the Year’s Most Damaging API Attacks, Breaches, and Exposures

The global API management market is projected to generate around $9.7 billion in revenue this year (depending on the source, estimates range from $7 billion to $ 12 billion), underscoring that APIs are now the connective tissue of modern business—and a growing attack surface.

This last point is emphatically confirmed by this year’s most damaging API security incidents and exposures:

• Stripe’s legacy API attack (merchant-targeted skimming campaign)
• McDonald’s / Paradox.ai data incident
• Intel employees’ data exposure
• Volkswagen’s multiple API flaw
• Azure AD users’ sensitive information exposure

You will learn the technical root causes and the key lessons from these incidents.

Security professionals and developers can approach these five API incidents as case studies for learning and improvement. Chronicles of how exploiting API logic flaws, technical vulnerabilities, and security oversights result in operational disruptions with lasting business fallout. Signs that preventing an API security incident must be the cornerstone of any security strategy.

Note: Not all these incidents involved confirmed malicious exploitation. Some were researcher-disclosed exposures, included here because they highlight the same systemic API security weaknesses attackers routinely exploit.

1. Stripe’s Legacy API: The Ghost of Technical Debt

This attack did not compromise Stripe’s core, current infrastructure. Instead, it was a web-skimming campaign against merchants that abused a deprecated, legacy Stripe API endpoint. This forgotten doorway became a prime vector for a large-scale card-testing and skimming operation, illustrating the dangers of zombie and shadow APIs.

The Anatomy of the Attack

Attackers found a legacy endpoint (/v1/sources) that was still connected to backend payment validation systems. This endpoint lacked the security controls of Stripe’s modern APIs, such as advanced rate limiting and fraud detection algorithms.

They used stolen card lists and bots to flood the API with small transaction requests. Each request provided valuable information, regardless of whether it was successful or unsuccessful. A successful transaction confirmed the validity of a card, marking it for fraudulent use or sale on the dark web.

The core problem here was a combination of Improper Asset Management and Broken Authentication vulnerabilities. The legacy endpoint lacked the stringent authentication of Stripe’s production APIs. It was a remnant of older architecture—poorly documented and overlooked in security audits.

This is not unusual. On average, organizations test only 38% of their APIs for vulnerabilities, leaving legacy or shadow APIs dangerously exposed.

Since this API endpoint was not part of the official inventory, Stripe didn’t subject it to the same rigorous testing and monitoring as other APIs. That allowed the attackers’ high-frequency, low-value requests to fly under the radar of standard security alerts for an extended period.

The Stripe API Attack Mechanism
Initial Compromise	Attackers injected malicious JavaScript into merchant e-commerce websites, exploiting vulnerabilities in platforms such as WooCommerce, WordPress, and PrestaShop.
Skimming Script Deployment	The script overlaid Stripe’s legitimate iframe with a counterfeit one.
Card Validation via Stripe API	Captured card details were sent to the deprecated endpoint for validation; only valid cards were exfiltrated.
Exfiltration Method	Data was Base64-encoded and transmitted to attacker-controlled servers.
User Deception	Victims saw a fake error message after entering card details.

Impact and Lessons Learned

The Stripe API incident affected at least 49 online retailers.

It highlighted a critical challenge for mature technology companies: managing the life cycle of digital assets. As platforms evolve, they deprecate existing APIs in favor of new versions. However, if they do not decommission the APIs fully and securely, the latter become a continuous lurking threat.

This campaign underscores the need for a comprehensive, continuously updated API inventory. Proactive security testing platforms are crucial in this context. For instance, by simulating attacks that probe for authentication weaknesses, they can identify shadow APIs and flag vulnerabilities before adversaries discover them.

2. McDonald’s / Paradox.ai: A Failure in the Supply Chain

The McDonald’s McHire platform data incident was a textbook example of third-party security risk. Vulnerabilities in Paradox.ai’s system—the company that provides the AI-powered chatbot used to screen job applicants—led to the exposure of sensitive data belonging to the major corporation.

The Anatomy of the Attack

The security researchers investigating the McHire platform discovered two critical flaws:

• An administrator account on the McHire platform secured with the default username and password combination: 123456:123456. The weak credentials gave them admin access to a test restaurant account. This account, which should have been decommissioned years prior, lacked multi-factor authentication and provided an initial foothold into the system.
• Once inside, the researchers identified a severe Broken Object Level Authorization in the API that managed applicant data. The API endpoint for retrieving an applicant’s chat logs and personal information used a sequential ID number in the request. By incrementing the ID number, the researchers could cycle through the records of applicants without any authorization checks.

The API failed to verify whether the authenticated user (in this case, the compromised test account) had the legitimate right to access the requested data object (the applicant’s record). That made it possible to access a trove of personally identifiable information:

• Names
• Email addresses
• Phone numbers
• IP addresses
• Chat histories
• Personality test results

Impact and Lessons Learned

This incident exposed the personal information of approximately 64 million applicants.

McDonald’s correctly stated that the API vulnerability was with their third-party provider. However, the reputational damage primarily fell on them. For the millions of job seekers, it was the McDonald’s brand they had entrusted with their data.

This breach is a critical lesson in supply chain security. When an organization integrates a third-party service via an API, it inherits the security posture of that vendor. Therefore, vetting vendors is a must. Moreover, it is not a one-time process; it requires continuous assurance as the vendor’s environment changes.

This is where automated offensive API security testing becomes indispensable. A platform that can test for complex business logic flaws can also identify a BOLA vulnerability. By manipulating object IDs in API requests and analyzing the responses, it can detect when the system fails to enforce proper authorization.

3. Intel: When Internal APIs Become External Threats

The “Intel Outside” API incident was a researcher-disclosed exposure that showed how external actors could have discovered APIs intended for internal use with serious consequences.

The Anatomy of the Attack

The prominent ethical hacker Eaton Zveare gained initial access through the Intel India Operations partner portal. Once inside it, he began mapping the application’s behavior and discovered calls to an undocumented API endpoint.

This API was designed for an internal administrative function and assumed a trusted environment. As a result, it suffered from critical Security Misconfiguration and Excessive Data Exposure vulnerabilities.

The API endpoint’s purpose was to retrieve user profile information. A standard request for a user’s data would return a JSON object with basic details.

However, the developers had not properly sanitized the API’s output. By manipulating parameters in the API request, the hacker found he could trigger a more verbose response that included internal metadata, role permissions, and, in some cases, session tokens for other integrated systems.

The API sent complete data objects to the client, relying on the client-side to filter sensitive fields.

This practice is common but extremely dangerous. It allows an adversary, interacting directly with the API, to bypass the client-side interface and receive a full, unfiltered dataset.

The unauthenticated API access was enabled by exploiting the getAllAccounts function in the Microsoft Authentication Library (MSAL) JavaScript. The hacker was able to bypass the Microsoft Azure Active Directory (AAD) login, triggering an unauthenticated getAccessToken endpoint that granted access to detailed employee information:

• Names
• Roles
• Managers
• Phone numbers
• Mailing addresses

By removing filters in the API request, Zveare could retrieve a nearly 1GB JSON file containing comprehensive data on all Intel employees.

In addition, he discovered hardcoded credentials on multiple internal Intel platforms:

• Product Hierarchy
• Product Onboarding
• SEIMS Supplier Site

Attackers could easily decrypt the credentials, enabling further exploitation, including potential administrative access and unauthenticated access to supplier data.

These flaws provided the hacker with a clear path to harvesting vast amounts of sensitive data from both employees and suppliers, amplifying the incident’s impact.

Impact and Lessons Learned

The exposed data enabled the researcher to demonstrate how easily an attacker could escalate privileges and exfiltrate proprietary technical documents and employee information. The exposure covered personal data of over 270,000 Intel employees and suppliers.

This incident highlighted the fallacy of the trusted network model. In a modern security architecture, organizations should never grant implicit trust to API calls, whether internal or external.

Automated API security tools are essential for this purpose. It can analyze API responses to identify instances of excessive data exposure. That way, it flags endpoints that return more information than necessary for the function they are supposed to perform.

Likewise, understanding the business logic of an application is crucial. A security platform that can map the relationships between different API functions can also identify how an attacker might chain together seemingly low-risk vulnerabilities to achieve a high-impact compromise.

4. Volkswagen: The Connected Car Becomes an Attack Vector

The Volkswagen API case was based on a responsible disclosure by a researcher, not a confirmed criminal campaign. Still, the vulnerabilities showed how dangerous weaknesses in connected car APIs can be.

The Anatomy of the Attack

A security researcher discovered multiple API vulnerabilities in the “My Volkswagen” application:

• When registering a vehicle, the app required an OTP sent to the previous owner. The API endpoint responsible for validating this OTP had no rate limiting, lockout, or anomaly detection in place. By intercepting the request, the researcher identified the exact endpoint and parameters used for OTP verification. This is a classic example of Broken Authentication.

  Then, he used a multithreaded Python script to brute-force all 10,000 possible four-digit combinations. Since the API’s responses clearly indicated whether an OTP was valid or not, the attack succeeded within seconds, granting unauthorized access to the vehicle’s digital profile.

• This initial access exposed further weaknesses. The researcher discovered that Excessive Data Exposure affected multiple API endpoints. Instead of enforcing field-level filtering, the APIs returned entire objects in JSON, including sensitive values never intended for client-side use.

  Among these were plaintext internal credentials—usernames, passwords, and session tokens for backend services such as Salesforce CRM, payment processors, and other internal systems. Without encryption or masking, the credentials were directly usable by anyone with API access.

• More alarmingly, another API endpoint exhibited a severe BOLA vulnerability. By substituting the VIN (Vehicle Identification Number) in requests, the researcher could enumerate arbitrary vehicles.

  The received responses contained a wealth of sensitive data:

  • Owner PII: full name, email, phone number, and postal address
  • Vehicle data: registration number, engine number, warranty and contract details, insurance information, and complete service history
  • Telemetry: fuel and engine statistics, tire pressure, mileage, and geofencing settings
  • Real-time vehicle location data (in some instances)

These API endpoints lacked authorization checks that bind the requesting user to the vehicle’s identity. That meant anyone with a valid VIN could access sensitive records belonging to other owners.

Impact and Lessons Learned

The flaws exposed sensitive owner and vehicle data. Volkswagen acknowledged and fixed the issues after disclosure.

In the automotive industry, where API failures can have life-endangering consequences, security must be an integral, automated, and continuous part of the development process.

To this end, integrating an automated security testing solution fueled by agent-based AI into the CI/CD pipeline is crucial. Such a solution can automatically test for these very issues, simulating brute-force attacks on authentication endpoints and manipulating object IDs to check for authorization failures.

5. Azure AD Users: The Danger of Exposed Endpoints

This API incident is an example of how a single, unsecured API endpoint can lead to mass exposure of sensitive enterprise data. It was discovered by researchers, who found that a client-side script exposed an unauthenticated backend API capable of minting privileged Microsoft Graph tokens.

The Anatomy of the Attack

The incident stemmed from a severe Security Misconfiguration and poor API asset management. Developers embedded a client-side API call in a JavaScript file to fetch user data for an internal dashboard.

The linked backend API endpoint was left unauthenticated. When invoked, it generated an OAuth 2.0 app-only access token (JWT) for Microsoft Graph via the client credentials flow. The token carried high-privilege application permissions:

• User.Read.All: complete directory user enumeration (GET /v1.0/users with OData pagination)
• AccessReview.Read.All: read access to identity governance reviews, including assignments and decisions

Since no authentication or caller restrictions were enforced, anyone on the internet could obtain a valid Graph token. Using this token, attackers could directly query Microsoft Graph endpoints.

The API returned paginated directory data, exposing the information of over 50,000 Azure AD users at one organization, though there is no evidence of widespread malicious exploitation:

• Full names
• Job titles
• Email addresses / UPNs
• Manager and reporting structures
• Contact details (if present)
• Access review information

The misconfigured API acted as an anonymous proxy, giving outsiders privileged Azure AD access for phishing, social engineering, and privilege escalation.

Impact and Lessons Learned

This incident demonstrates the danger of exposing sensitive logic in client-side code. Because these scripts are public, any API endpoints they reference must be considered insecure by default and require robust authentication and authorization.

A suitable API security platform, like Equixly, addresses this issue in the following ways:

• Through API discovery, it flags a new, unauthenticated endpoint
• By analyzing the application’s business logic, it determines whether an API endpoint grants unusually high-privilege access tokens
• By monitoring data flow, it detects whether adversaries exfiltrate sensitive PII through an unauthenticated channel.

Conclusion: From Afterthought to Foundation

The five 2025 API security incidents and exposures described here are not the result of exotic exploits, but of fundamental security omissions. From forgotten legacy endpoints and broken authorization to excessive data exposure, they prove that the greatest threats lie in what is unmanaged, untested, and untracked.

To prevent the next wave of incidents, organizations must treat every API as a critical asset and embed automated security testing into its entire life cycle.

Don’t let history repeat itself! Schedule a demo and see how Equixly uncovers vulnerabilities behind these incidents—before they become tomorrow’s breaches.

FAQs

What are the most common root causes of major API breaches?

Major API breaches often materialize from common architectural oversights and misconfigurations, such as

• Broken object-level authorization (BOLA)
• Authentication weaknesses
• Insufficient rate limiting

These are inherently challenging to identify and mitigate consistently within high-velocity CI/CD pipelines. That only underscores the critical need for automated testing that can comprehend complex business logic.

Our business integrates with many third-party services. How do we manage the API security risks from vendors?

Managing vendor API risk requires moving beyond slow, trust-based assurance, as traditional methods fail to keep pace with the speed of development. The effective strategy is continuous, automated validation of third-party endpoints in a pre-production environment.

This approach proactively discovers inherited security flaws, such as excessive data exposure, and is the emerging standard for securing an API supply chain you don’t directly control.

We have a large and evolving application environment. How do we address the threat of undocumented or forgotten APIs?

Undocumented (shadow) APIs and deprecated but active (zombie) APIs are inevitable byproducts of high-paced development and microservice architectures. They exist outside of standard security controls and CI/CD pipelines, resulting in a substantial unmonitored expansion of the attack surface.

Effective mitigation requires transitioning from static definitions and periodic manual checks to continuous API testing and discovery. The purpose of this shift is to build a dynamic and continually updated inventory of endpoints.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.