Developers: Is Your API Designed for Attackers?
When an organization has a security problem with an API, it’s usually one it built internally, according to Jeremy Snyder, founder and CEO of API security firm FireTail.io.
The security firm analyzed 40 public breaches to see what role APIs played in security problems, which Snyder featured in his 2023 Black Hat conference presentation. The issue might be built-in vulnerabilities, misconfigurations in the API, or even a logical flaw in the application itself — and that means it falls on developers to fix it, Snyder said.
“It’s a range of things, but it is generally with their own APIs,” Snyder told The New Stack. ”It is in their domain of influence, and honestly, their domain of control, because it is ultimately down to them to build a secure API.”
The number of breaches analyzed is small — it was limited to publicly disclosed breaches — but Snyder said the problem is potentially much more pervasive.
“First of all, 83% of all internet requests, if not more, are API requests,” he said. “It’s not the total volume of traffic. It’s the number of requests that are flowing across the Internet day to day, more than four-fifths of all requests are actually API requests, not user-initiated queries.”
In the last couple of months, he said, security researchers who work on this space have uncovered billions of records that could have been breached through poor API design. He pointed to the API design flaws in basically every full-service carrier’s frequent flyer program, which could have exposed entire datasets or allowed for the awarding of unlimited miles and hotel points.
“We’ve seen a few very, very high-profile examples,” he said. “Effectively the entire connected car ecosystem has had API design flaws that could have exposed not only the owners of all of these vehicles, [but that] allows you to update the owner records, allows you to unlock and start these vehicles and drive them away.”
Snyder explained some of the top API problems and outlined best practices developers can use to improve APIs.
Common API Flaws
Indirect Object Reference, or IDR, is a common problem, Snyder said. It allows someone with a legitimate user’s access to manipulate the API request to access another user’s data.
“That is a super common — that may be, on its own, the single number one problem that we see consistently across the data set,” he said.
Another common problem is excessive data exposure, in which the API returns too much data. For instance, a page might have a photo, your name, an address, whatever, and the API sends everything — including personal data. Then the developer relies on either the mobile app or the web browser to hide all the data that wasn’t requested.
“Of course, bad actors don’t play by those rules,” he said. “They’re not going to go through your app or go through your web interface to try to scrape data from your API.”
Developers aren’t doing this on purpose, but mistakes happen when other pressures mount, he added.
“I don’t think any developer sets out to intentionally return too much data or to intentionally build a bad API,” he said. “But I think there’s a trade-off between how quickly I can build something — speed and convenience versus the security and privacy considerations.”
Best Practices to Fix API Flaws
Write a specification. Very few developers start from absolute zero when they’re building an API, Snyder noted. Typically, they’ll use a common open source framework for building that API. Part of that initial work should include a specification file governing how the API should work, he said.
Use common tools. Don’t try to create your own kind of identity and authentication mechanisms, Snyder said. “There’s everything from WebAuthn to single sign-on mechanisms and the less you make yourself build and design around identity, the higher the chances that you could get it right easily by leveraging a proven solution,” he said.
Think about the data. “Think about designing your API in a way that doesn’t expose too much and also is like checking an authorization for each data request,” Snyder suggested. Sometimes, developers push that authorization check to the frontend on a mobile client or Internet of Things device. In one famous case, the authorization was happening inside the logic of a Peloton exercise bike. “Again, you know, hackers don’t play by those rules, so they went straight to the Peloton API using the scripting language,” he said. “They just started manipulating authorization requests and they were able to extract about 3 million records.”
