API Security in the Wild
“[Company] suffers data breach, millions of customer affected”
Everybody has seen this headline multiple times. Most recently, it was T-Mobile, but in the last three years that has also been Instagram, Facebook, Tinder, Air Canada, Panera, the IRS, and the most devastating of all, Equifax. Those are just the ones we know about. Luckily, the T-Mobile attack was mitigated by network and traffic monitoring, but that makes them the exception.
What all of these breaches all have in common is their API design and their fundamentally flawed approach to security which most likely occurred due to a simple reason: the use cases and users the API was designed for changed over time and no one realized the initial assumptions, constraints, and requirements had also changed.To put it another way, our APIs are being used for applications and situations we never envisioned.
Unfortunately, that doesn’t absolve us of responsibility. The entire point of APIs is to allow and encourage new use cases, new business models, and remixing in ways we didn’t imagine and can’t predict. With that in mind, there are specific steps we can take at the design stage to make sure our APIs are more secure in unpredictable scenarios.
1. Authorize, Don’t Just Authenticate
Intellectually, while we understand authentication is who we are and authorization is what we’re allowed to do, that same realization rarely makes it into our APIs. In fact, many of the API breaches mentioned above did not have any limitations in the data someone could request or actions they could take once they were authenticated.
We need to reinforce these distinct but linked concepts. As I noted in Security and the API Journey, authorization is not a simple binary state. It depends on the user, their context and their desired actions. For example, while I may be able to see and interact with my information, downloading an entire customer database is probably not a valid use case.
2. Design, Don’t Just Deploy
No matter your programming language or framework of choice, there are tools to launch your API quickly. These tools are enticing because they claim to solve all your problems with minimal effort, minimal code, and in a matter of days. The problem, is that most of them lack any sort of built-in authentication, authorization or even recommended practices for either. They lull us into a false sense of confidence that our API is complete and then we move on to other tasks.
Fast forward days, weeks or months, and we have internal apps using the API. Our mobile developers have launched great, new customer apps. And then someone takes a deeper look at our apps and realizes there’s an unprotected API behind the scenes. In the case of Panera, customer names, addresses, phone numbers, email addresses, and even food allergies were unwittingly left out in the open for anyone to access. While not devastating alone, when combined with other data a malicious actor can go on to exploit that information with online retailers and deal financial harm to a person.
3. Don’t Collect Unnecessary Data
On that note, we should think carefully before we collect data. If we don’t need a user’s credit card number, social security number, or any other sensitive information, don’t collect it. A payment company like Stripe can process transactions. Identity leaders like Okta can handle user passwords. If we don’t store the information, it can’t be leaked via our API, database backups, or via a developer building a development environment. It’s a prudent, responsible decision that reduces risk for our companies, teams, and individual developers.
4. Don’t Share Unnecessary Data
In the scenario where we must store sensitive information, we need to scope the data shared to the specific use case. If you have an API to assist patient scheduling, the receptionist doesn’t need the detailed medical records that the physician does . Simply by segmenting these groups and the permissions that come with them, we protect our users better and often reduce our legal liability.
Then there are scenarios where information is collected that we will never return via the API. At Okta, for example, when you create a user, you can specify their password. We hash it and store the result but never return it. This protects us, our users, and defends against bad actors who may try to attack the hashes with rainbow tables or the like.
5. Monitor, Monitor, Monitor
Launching an API is a team sport. Too often, developers build something great, throw it over the wall to the Ops team and move on to the next tasks. As we move towards launch and our API gains adoption, we need to estimate what is “normal” and take a close look at anything outside of that pattern. In the case of T-Mobile, the network and security team that realized something was wrong, tracked the issue, and were able to shut down the attack in progress. While we won’t always catch an attack live, we can’t let it continue for weeks or months like Panera and Equifax.
Gartner projects that, by 2022, APIs will be the top attack vector for the biggest and worst data breaches. Personally, I suspect it’s going to be bigger and happen sooner than they predict. Further, as we connect more systems and to the world around us, it’s only a matter of time before a vulnerability in a seemingly meaningless system affects the safety, both digitally and physically, of people on a massive scale.
We have a decision in front of us. We can be more careful and deliberate about our design choices and the implications of choices, or we can suffer through a generation of fraud, abuse, and scandal. It’s up to us to prevent that nightmare.
