In the ’90s, “hacker” was a bit of a dirty word. Movie hackers sported edgy names like Electra (Assassins), Neo (The Matrix), Phantom Phreak (Hackers), and Boris Grishenko (Goldeneye). Great taste in Hawaiian shirts, less so at coming up with plans to defeat James Bond.

These godlike characters are vital to their respective films, their last-minute code cracking almost always the key to obtaining access to the MacGuffin. Thirty years later, hoodies have replaced the Hawaiian shirts and l337 speak has mostly been abandoned.

Some things, however, haven’t changed. Although attitudes towards hackers have softened in some ways — YCombinator’s message board Hacker News is an homage to them, after all — they still retain an air of mystery among the general public. Perhaps, thanks to recent high-profile cybercrimes, even an air of danger.

However silly it may seem, this is a valuable headspace for developers to enter sometimes. At least, that’s how Dan Barahona of APISec University sees it. At our 2024 Austin API Summit, Barahona joined us to advocate for trying to hack your own APIs.

In this post, we’ll draw some actionable takeaways from that talk and examine how this view of APIs might help you approach security in an entirely new way. Grab a Monster energy drink and a pair of armless sunglasses, and dive into that waterfall of green code with us.

Why Attackers Love APIs

Barahona starts his talk with a quick overview of what makes APIs attractive to attackers. Namely, that they enable them to circumvent the need to engage with the UI of web or mobile apps, which may have extra layers of protection. According to Barahona, hackers will often look for APIs that are over-permissioned, return too much information, access unauthorized functions, or expose logic flaws.

He also points out that this is much more than just an academic exercise — problems with APIs have been responsible for several real-world breaches. For example, Coinbase had a missing logic validation check, resulting in an exploit that allowed a customer to issue a trade worth $43,000 that he was not authorized to — something that could never have been done through the front-end UI.

Barahona also provides the example of Peloton’s leaky API, which allowed access to the account data of millions of riders… even if they had marked their profiles as private. “The pro tip here,” he quips, “is that authentication is not the same thing as authorization.”

Coinbase addressed the exploit after being tipped off by the customer in question and rewarded him with $250,000. Although this post will focus on securing APIs yourself, bug bounties are worth mentioning as a valuable way to encourage people to take a crack at finding issues.

Takeaways From Breach Analysis

In their 2024 API Security Market Report, APIsec University breaks down the most common causes of recent data breaches and correlates them with OWASP’s Top 10 API Security Risks:

• Rate limiting (70% of breaches) – OWASP #4
• Broken authorization (60%) – OWASP #1
• Broken authentication (45%) – OWASP #2
• Excess data exposure (30%) – OWASP #3

Despite factoring into more than 70% of breaches, Barahona says that “rate limiting isn’t going to protect everything. Not having it makes things worse — instead of losing 100 records, you might lose 100 million — but it’s not the root cause of API vulnerabilities.”

We also recently highlighted that rate limiting isn’t a silver bullet for preventing data breaches. Despite coming behind rate limiting, numbers 1, 2, and 3 on OWASP’s Top 10 play a part in a combined 90% of notable breaches.

Barahona suggests that the root problem behind many breaches is that there’s something interesting to harvest. Take the recent Trello leak, for example, in which 15 million user records were obtained via an exposed API.

“If you only need to send a first name,” Barahona asks rhetorically, “why would you ever send last name, home address, account number, email address, or anything else in that record?”

The Problem With a Typical Developer Mindset

As developers, we may be more concerned with ensuring things work correctly (and well) than making sure they’re doing so securely or as concisely as possible. If that statement sounds glib or painted with broad brushstrokes, it’s backed up by hard numbers:

Postman’s 2023 State of the API Report confirms that, while 67% and 64% of respondents conduct functional and integration testing, that number drops to less than 50% for security. And that may be because we’re thinking like developers, not attackers.

Referring to a Duolingo leak, Barahona makes the following statement about a hacked API that was not publicized, but left unsecure: “I can only imagine that the developer of this API probably thought ‘who’s ever going to find this thing? What would be the point in them using it?'”

“But your hidden APIs,” Barahona concludes, “will be found.” When you spend a little time in certain corners of the internet, you’ll know that something absurd, pointless, or obtuse offers no guarantee that it won’t happen. Just take the world of gaming, for instance. From crossing Red Dead Redemption 2’s entire map without taking a step to the cult of 360 no scopes, there is always someone out there trying to do just about anything pointless that you can think of.

In many cases, the hacker mindset is driven by curiosity: a desire to prove that something can be done just for the sake of proving it. Never assume that your API is safe just because you don’t publicize it or because it doesn’t send much useful information. Of course, there are some instances in which an attacker’s approach is driven by aims that are much more malicious than innocent curiosity.

Understanding How Hackers Think

Back in 2017, The Economist wrote that the world’s most valuable resource is no longer oil, but data. Botnets, hacking, ransomware, and so on have a significant presence on the dark web, often with the common aim of acquiring user data to be sold.

As the volume of that data scales, so too does the value its sale can command. And, as we’ve seen from the breaches above, APIs are an appealing way to secure massive amounts of data.

Attackers are clever, and they’ll find ways to exploit APIs, says Barahona. “They’ll use proxies, rotate IP addresses, and throttle their own requests. They’ll use all these techniques, even if it takes months to pull off.” In other words? Never underestimate a hacker with their eye on the prize.

The API Security Lifecycle

Barahona suggests various points where you can implement API security measures in the API lifecycle, with the aim of mitigating such attacks.

When it comes to combating attacks, he proposes the following methodology:

• Automate: eliminate manual testing as much as possible
• Comprehensive: test every endpoint across OWASP and more
• Continuous: integrate testing into SDLC, i.e. shift left

“Manual testing is all well and good,” Barahona says. “But it’s not going to be able to keep up… If you have an API with 100 endpoints and you want to test authorization, authentication, data exposure, etc., you’ve got thousands of permutations. And if you’re doing a nightly build, you should be testing nightly. We need to take advantage of clever test generation capability.”

If implementing these processes sounds like a lot of work, consider this: would you prefer to explain to thousands or millions of users why their data has been compromised instead? We know which one we’d opt for…