The following three API security breaches provide helpful lessons for improving security today. One might ask, “Why select older incidents? Why not highlight just the new ones?” Two reasons: With the older ones, there’s often more to learn because they’ve had more time to be investigated and more is written about them. We can see that some things don’t change, despite all that has been written. And that can be used as a lesson in our own organizations. I’ve selected the three examples below because, together, they demonstrate the traditional and continued need for technical, managerial, and leadership oversight. Panera Data Leak In late 2017, Panera’s unauthenticated API allowed anyone to query certain info about anyone. This included name, email address, home address, and SSN. A security researcher notified Panera about the vulnerability in August. Long story short, it wasn’t fixed until April 2018. Details 37 million customer records (227,052,199 files) were leaked, though no one knows if it was discovered by criminals and acted on. Panera notified customers that they should beware of phishing emails and be on the alert for financial fraud. The security researcher who reported it made a post on Pastebin stating that an: “unauthenticated API endpoint that allows anyone to access the following information about anyone who has ever signed up for an account to order food from Panera Bread.” While the original Pastebin notification has been removed, you can see it here on : Archive.org https://web.archive.org/web/20180403004035/https://pastebin.com/21H28TA1 The vulnerability appears to have been ignored by Panera for more than 8 months. Panera's CIO had been notified by a security researcher, but there was no definitive action taken. Lessons Broken Object Level Authorization is the , creating a wide attack surface due to the ease with which someone can hop from record to record within the database. most common API threat The API guardians could have fixed the misconfiguration by requiring database authentication. There are always misconfigurations and vulnerabilities, but there are plenty of resources and checklists available to provide guidance on common weaknesses to test. Though there’s often a leadership issue involved in the remediation of security issues, we can’t always immediately blame security leadership. Perhaps leadership didn’t take them seriously. Maybe the notices got lost in the shuffle. Or they might have been put on the list and never got attended to. But a lesson here is that leadership needs to have a plan for vulnerability notifications. USPS Data Exposure In November 2018, USPS had fixed a vulnerability in their Informed Visibility API. For at least a year, the records of over 60 million people were left exposed to anyone with a USPS account; anyone with a login could potentially view and edit any other users' account details. The data exposed included phone numbers, addresses, and usernames. Details You can view the API prior to the fix here: https://krebsonsecurity.com/wp-content/uploads/2018/11/USPS-ID-API.txt The security researcher notified USPS of the vulnerability in 2017, but the warning went for a year unaddressed. The researcher notified a noted journalist, who brought the vulnerability to the attention of USPS security leadership. The issue was addressed within 48 hours. Was there a breach? This was often marketed as a breach, but we don’t know if there was a criminal breach. It's only known that the data was exposed. Lessons This example of Broken User Authentication is another common problem, and the way it was addressed so quickly shows that it was a relatively easy mitigation. Additionally, the privacy exposure was another brick in the wall of privacy issues that have led to the data privacy regulations we have today. Parler Breach As a result of the shocking events at the United States Capitol on January 6, 2021, social media service Parler’s involvement in the attack was questioned, prompting a hacktivist group to scrape data from the platform before it was taken offline for a time. Details 70TB of data was extracted, consisting of user messages, posts, and videos. Many of these were supposed to have been deleted. Some don’t consider the Parler incident as a criminal breach, but rather something (scraping) that anybody could have done because it was designed that way (meaning, poorly designed) and the laws about what constitutes digital theft and intrusion did not address this type of occurrence. reports Whether it is deemed illegal or not, even if something is not considered a punishable breach, an organization’s reputation as to how it handles user data is of paramount importance. One of the many issues was, like with Panera, Broken Object Level Authorization, formerly known as Indirect Object Reference. E.g., let’s say my account is ID1, yours is ID2, and everyone else is in sequence after that. If our known APIs are /api/ID1 and api/ID2, then all of the other accounts can be pulled by GET requests to the following numbers because the only fuzzing needed involves numbers after ID. Lessons In between the first 2 incidents and the Parler incident was the publication of the OWASP API Top Ten in 2019. Parler’s incident is not alone in its apparent neglect of attending to well-known API vulnerabilities because it entailed numerous common weaknesses. Two mitigations would have provided technical fixes for multiple issues: random and non-guessable IDs, and restricted access to those APIs It’s important to have well-thought-out and vigorously reviewed policies in place that state what can and can't be done with data. These policies are part of layered security. Security involves more than just addressing technical protections; it involves old-fashioned information security. A corollary lesson is how a company will deal with extended downtime, whatever the cause. Moving Onward and Upward Organizations need to look at security in holistic, not just technical, ways. Beyond practices such as following OWASP API Top Ten and API documentation, questions such as “What data is supposed to be exposed?” and “Do we have public-facing policies that have been legally reviewed and that state plainly what data is to be used for?” need to be answered. A focus on technical elements of cybersecurity and not on overall information security and assurance will put an organization in a tenuous position of improper oversight, if not downright neglect. Companies also need to consider privacy in their security planning, design, and architecture. Just as important as the speed of business is the stability of business. API security is a cornerstone of that stability, and it’s possible with the right leadership support.

Protecting APIs from DDoS Attacks

API Architecture: Components and Best Practices 

Too Long; Didn't Read

Make resilience your competitive advantage

Breaking Down 3 API Security Breaches

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

5 Reasons Traditional Security Tools Fall Short in Protecting APIs

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

5 Reasons Traditional Security Tools Fall Short in Protecting APIs

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps