Peloton’s API leak: Security requires a combination of technology and processes

enterprise API management

Recently, a long-lasting security vulnerability exposing private user data through Peloton’s API was made public. It’s worth diving into what happened, as it’s a rather typical API-related security issue with implications for enterprise API management.

Peloton is the well-known maker of high-end exercise equipment (stationary bikes and recently troubled treadmills) whose sales surged when people were suddenly confined at home last year. The company stood out by combining high-quality exercise equipment with an immersive digital experience, offering subscription services for guided workouts and classes. This means the equipment has to be online, and Peloton has companion mobile and web apps as well.

Application Programming Interfaces (APIs) are necessary ingredients of IoT (Internet of Things) services such as Peloton’s. They are the access points that enable both the equipment and the user-facing apps to access information on Peloton’s servers.

So, what went wrong?

The technology failure

In Peloton’s case, these APIs were not meant to accessed by somebody else’s applications. APIs can be classified as private, partner, or public APIs, and Peloton’s were designed to be private. The intention was that only Peloton applications (on their equipment or the user-facing apps) would access them.

At the same time, because of the APIs’ goals (to be reachable by equipment and users from all over the world), they had to be exposed externally, as opposed to internally (i.e., just on a company’s private and protected intranet).

While this may seem a bit contradictory at first, this combination of private/external makes a lot of sense and is very widely used nowadays. As more and more “connected things” and apps are created, they need to communicate with APIs intended to be accessible only to them. These APIs need to be exposed externally because they aren’t only accessed from within a company’s private intranet.

The reported vulnerability allowed API requests to access profile information of Peloton users. With millions of customers worldwide, this means that anybody anywhere could get access to the user profile information of all Peloton users, including name, age, gender, and location.

It was possible to retrieve information about specific users or to search for users matching certain criteria. It was also possible to retrieve information about users who had set their accounts to “private,” expecting that this would prevent their information from being seen by others.

At that point, this was a typical API leak similar to many we’ve seen recently, with companies assuming that a private API does not need to be secured. Wrong. If a private API is externally accessible, it absolutely has to be secured. (Increasingly, companies are securing internal APIs as well because many networking breaches lead to attackers gaining access to intranets).

This vulnerability was reported to Peloton on January 20th, 2021. The company reacted in a little over a week, responding to the report on February 2nd. However, that fix was grossly inadequate. It simply limited API access to authenticated users, meaning that anybody with a Peloton account (of which there are millions, and anybody can sign up any time for a new account) could still access that data.

It’s important to understand why that initial fix was relatively quick, and also a technology failure: Peloton relied on their apps (on their bikes and on their user’s phones) to “hide” the private information of others, leaving the APIs themselves exposed.

It’s relatively easy for an API to be configured in certain ways. Peloton configured theirs so certain conditions had to be met (such as an “authenticated user” token) before granting access.

However, to properly hide information that should not be exposed through the API (such as private account details), the application code implementing the API needs to be changed, which is typically more complex and time-consuming because the development team needs to plan and implement the updates, and then the code has to be “put into production” (i.e., released to the servers) to finally fix the security issue.

The process failure

And this is where Peloton ran into a process failure on top of a technology failure. Instead of treating the initial reaction as a quick but inadequate fix, it appears they considered the security issue resolved. This is a sign of a process for reporting and addressing issues that are not properly designed and managed.

The security researcher who found and reported the vulnerability did not get any updates from Peloton after the initial quick and inadequate fix. After waiting for 90 days, he contacted a journalist who then contacted Peloton on his behalf.

This escalation set things in motion again. At that point, the process failure on Peloton’s side was probably fixed and the still-open issue was addressed. It took Peloton seven days to finally fix the security issue after the escalation through the journalist, and it seems as if the data leakage through their APIs has now been stopped

Given that millions of people (including many high-profile Hollywood celebrities and reportedly even U.S. President Joe Biden) are using Peloton, it seems like fixing the reported vulnerability should have been much faster than three months. And given the fundamental misunderstanding of enterprise API management basics, it also feels as if this might not be the only API-related problem the company has. Hopefully, this incident has led to a thorough internal security review and overhaul of the current processes.

What we can learn

This is neither the first time this narrative will play out, nor will it be the last. Generally speaking, many organizations are quick to embrace the potential and possibilities of connected devices and apps, but slow to make sure all the right technology and processes are in place to make them secure.

Technology means to understand APIs in terms of the private/partner/public differences, but to also understand that these differences are not the same as internal/external. An API strategy and a well-managed API management platform have to be in place so the teams exposing APIs to anybody will be able to do a thorough security review before they roll out certain API designs.

While the cost of treating API security seriously might seem unnecessary at first, the steady stream of API-related security problems shows that ignoring API security comes with considerable risk.

Process means that reported issues must be handled in such a way that a full assessment of the impact and scope of reported vulnerabilities is conducted, and processes are in place to make sure that all issues are resolved in a timely manner.

The cost/benefit consideration is the same as on the technology side: it might seem like unnecessary overhead, but Peloton’s failure shows that having poor processes can result in even bigger issues down the road.

Moving on

In the Peloton case, it’s not clear if their API issues led to hackers exploiting the data, and without a solid enterprise API management strategy, they may not have a way of finding out. Let’s hope for the best, and be grateful this vulnerability did not include more problematic data such as credit card numbers or exact home addresses.

The important lesson we can take away from the Peloton leak is that many companies still do not treat APIs as first-class citizens of the business. Having an explicit enterprise API management strategy and an internal API program to put the strategy into action can help prevent that can cost companies in terms of monetary and brand damage.

Not everybody in an organization has the expertise to fully understand how APIs work, how to design them, and how to manage them securely. But today’s connected companies should have structures in place to make sure that API design, implementation, and management are done properly.

For Peloton, this incident was probably a very good wake-up call. For others out there: If you have anything connected to your servers (equipment, apps, partners), no matter how “private” you think these connections are, make sure you have sufficient API maturity to manage them well. You don’t want to end up in the news like Peloton.

Do you need help making sure your technology and processes will keep your APIs, your customers’ data, and your company’s reputation safe?

Previous articleGermany’s Bundesagentur für Arbeit enables secure, efficient eGovernment services powered by Axway
Next articleAmplify Central Integration Webhooks – Subscriber Notifier
Digital Catalyst, Erik works in the Axway Catalyst team and focuses on API strategy, API programs, and API platforms. His main goal is to make sure that organizations make the right decisions for using APIs as the foundation of their digital transformation initiatives. Erik has a Ph.D. from ETH Zurich, is the author of many articles, papers, and books. He is a frequent speaker at global API events and contributes to standardization activities to help improve the way APIs are designed, managed, and used."


Please enter your comment!
Please enter your name here