Application Programmer Interfaces – APIs – are everywhere we turn and are the technology that underpins much of the interconnected state of the applications and services we rely on every day. By their very nature, they present a security challenge for both developers and cybersecurity teams alike.

Jennifer ShannonSome 90% of developers use Application Programmer Interfaces (APIs). A perhaps astonishing 83% of traffic on the internet is related to APIs. Are all our APIs secure? Of course not: in fact, 51% of API calls having no authentication.

Thus was the relevance of the presentation API Security - A Pentester’s Perspective at the ISC2 Security Congress 2024 in Las Vegas. Jennifer Shannon, senior security consultant at Secure Ideas, gave the audience an insight into how API security works and how she and her colleages earn a living from trying to defeat it.

Before explaining what pen testers do, it’s worth a quick reminder that they do it by agreement with and under contract to organizations who want their systems’ security tested. Without that agreement most security testing would unlawful. As Shannon put it: “As much as I love breaking into things, I love not going to jail more”.

The Rise of the API

Shannon began by acknowledging the massive growth in API usage, implied by a corresponding growth in the number of penetration tests taking place: 10 years ago one would see maybe three or four a year, but roll the clock forward to today and it’s more like two a month. She puts part of this growth down to the fact that APIs are simpler to implement than they used to be: “ SOAP APIs, which for anybody who's never used a SOAP API: It's XML, it's a little bit painful to use. Now we have REST and we have GraphQL. So they've just become increasingly more popular”. Shannon also pointed out that APIs are super-popular when outsourcing processing activity, citing card payment processing as a super-common example but also noting that many mobile apps are really just GUI front-ends making API calls back to the mothership in the background.

This latter point was important: it is increasingly common to see a single API and back-end engine providing services to both a web portal and a mobile app – not just banking, but across the board: “In essence, if I just focus all of my effort on testing that underlying API, I'm able to effectively cover the majority of the ground, as far as the web application and the mobile app goes”.

Which brings us back to an early observation about API security – or the lack of it. “Unfortunately”, continued Shannon, “I think as far as the security concerns with APIs go, there's not enough attention paid to them. So I don't think that … security concerns around APIs have progressed at the same rate as our usage of APIs has”.

Addressing the Malaise

Shannon pointed firmly to the OWASP API Security Top 10, which most of the room were not familiar with (thought its sister, the generic OWASP Top 10, is far more commonly recognised). The Top 10 points out the most common security mistakes in API development and deployment, and as in many security applications it is easy to make “schoolkid” errors. Let us take a few examples from the Top 10: “expose endpoints that handle object identifiers, creating a wide attack surface”; “Authentication mechanisms are often implemented incorrectly”; “unclear separation between administrative and regular functions”; and “an API is fetching a remote resource without validating the user-supplied [request]”.

“Very frequently I'll find that creating new accounts within the system will happen either in a sequential or very predictable manner in which case that allows me to very easily go through and start enumerating other user's data”, noted Shannon. Her observation that she reckons to see “admin/admin” username and password combinations several times a year raised a laugh in the room, and on the subject of rate-limiting (blocking access after an excessive number of requests or authentication failures) pointed out that implementing rate limiting in the web site layer has zero deterrent to the person attacking the API beneath.

Shannon’s story was full of examples of API insecurities, real and hypothetical that were resonating with the audience. A real school system whose developers did a decent job preventing staff from pretending to be the principal but not such a good effort at preventing students from doing the same. A hypothetical restaurant booking system with no rate limiting that a disgruntled ex-employee could run a script against and book it up for weeks. Real stories of systems with active APIs that were no longer needed and should have been decommissioned some time ago … or which have been updated with new versions over the years but where the older versions have never been turned off. A real toe-curling history lesson: “We found Windows 95 on a test. Somebody else that was on that engagement with me thought it was a joke because they didn't realize Windows 95 ever really existed. Yeah … it made me feel old.”

The Potential for Vulnerability

APIs have the potential to be far more vulnerable to attack because they listen to requests from computers, not people. Think what happens when we log into (say) our online banking portal, or even our online media. We have to log in, with a username and password, and assuming we have been sensible security-wise, we probably have to enter a multi factor authentication (MFA) code. In computer-to-computer communication the calling device can’t pull out its smartphone and hit “Approve” on the MFA push notification. MFA saves us all the time on user logins, but it can never save us at the API level.

Which means we have to be cautious with our APIs. Use the variety of tools that are out there to do some testing ourselves. Use references like the OWASP API Security Top 10 to second-guess the errors the attackers are likely to be trying to exploit. Engage API-capable pen testers if possible … oh, and don’t be afraid to let them past any API security tools you’ve placed in front of the system, because as Shannon put it: “We try to ask the clients to, at least for part of the test, turn [API security tools] off because the expectation is that an attacker would eventually find their way around any of those protections and be able to bypass them. And at some point then, are we only testing the protection versus what are we testing?”

As with cyber security in a general sense, remember that by doing some of the very basic protection and configuration tasks well, it will make a big impact to your API security … and will certainly put you ahead of the crowd and maybe cause at least some of your attackers to go and knock on someone else’s door.