Woman exercising on smart stationary bike at home showing need for API security

Peloton API Security Lessons Learned

As a current CPO and a career-long security professional, I believe there are several lessons to be learned from the recent rash of API security incidents (Peloton, Experian, John Deere, Clubhouse). For any company, be it a large, established Fortune 100, or a modern hyper growth company like Peloton, you need to adopt a Shield Right while you Shift Left strategy to protect yourself from API security threats. But what does this really mean? Let me explain..

One of the goals of the shift left movement is to improve API security by catching vulnerabilities and risks earlier, and that means collaboration between security and development teams. The era of security and development operating in silos is gone. We see it in our own customer base – app teams not in sync with security, often meeting for the first time when they are looking to use a product or when experiencing a security incident, which is too little too late. Shield right is the last line of defense, sometimes minimized by the momentum behind shift left efforts.

Shift Left encourages collaboration

An easy mechanism to foster collaboration is to engage in a conversation around a common framework like the OWASP Top 10 lists for API Security and Web Applications. Additional shift left activities to encourage team interaction include security training for development teams, security focused code reviews, and security specific app & API testing. All this in mind, the biggest concern I hear is will collaboration slow the development cycle down? And honestly it might. But, given the situation Peloton, Experian, and others are in now, I would bet my salary that if they could go back in time, they would accept that delay to ensure their APIs were not exposing personal data so easily.

While shift left efforts will minimize API risk exposure, it does not erase all concern. So how should security and development teams react if an API vulnerability notification arrives in your email? Wearing both a head of products and security professional hat, the first thing I would do is mark the date – the 90 day disclosure time clock is ticking. Next, engage cordially with the researcher to confirm the findings – both teams need to understand that the research community, by and large, is out to help, not hurt your business. Once engaged with the researcher, maintain communications. 90 days moves quickly and the last thing any organization wants is a call from a reporter asking for comments on a security incident your team knew about. In parallel, I would form a strike team to take the following steps:

  • A comprehensive code analysis from a security standpoint. If the team lacks experience in this field, consider bringing in outside support.
  • Immediately address all vulnerabilities – using the OWASP Top 10 lists is low hanging fruit – they are listed in top 10 form for a reason.
    • In the case of Peloton and Experian, authentication was lacking or insufficient (number two  on the list).
    • Verify the enumeration methods cannot be used to extract personal information from member and class IDs (number four  on the list).
    • Make sure the data marked as private by users, such as profiles, memberships, etc. don’t show up in search results and limit API return code verbosity to ensure that they only return the most basic information (number three on the list).
  • Integrate an API DAST (Dynamic Application Security Testing) tool in the CI/CD pipeline to detect such vulnerabilities before they go live.
  • Implement a security training program for the developers and dev-ops engineers.

Shield Right as the last line of defense

In most cases, the APIs are integral to the business and can’t be taken down as you address the API vulnerability. As part of the shield right efforts, a runtime API security solution can protect all your APIs, while the development teams address the vulnerabilities. In the case of Peloton, such a solution could have blocked unauthorized API calls to those vulnerable APIs, while developers work to implement strict authentication checks in the APIs themselves. Additionally, it could have prevented enumeration of members and their sensitive personal information from even authenticated users.

Some will argue that “Shield Right while you Shift Left” is not new. For web applications we had static, dynamic code analysis and security testing in place but we also deployed Web Application Firewalls (WAFs). So, what has changed? What has changed is the explosion of APIs and rapid pace of deployment due to agile development tools and processes. While most security teams were barely staffed enough to handle yearly releases of monolithic web applications and monthly updates to the WAF rules, the APIs can get updated on a weekly basis. The numbers of APIs and therefore the scope of the attack surface keeps increasing and spirals out of control fast. Therefore collaboration between security and development teams alongside a philosophy of “Shield Right while you Shift Left” is key to success.