There are a few reasons that the topic of API security has been popping up more and more as 2022 comes to a close.

Back in July 2021, Gartner predicted that by 2022, application programming interface (API) attacks would become the most frequent attack vector, causing data breaches for enterprise Web applications.

Was the analyst firm right? It's too early to know for sure since OWASP is still tallying the results.

API attacks are back in the news. It turns out the likely ingress point for the Optus breach was a lowly REST API. And someone has leaked all of the data stolen from the Twitter breach — which also involved an API.

When we talk about API security, we're referring to the measures and practices that we use to secure APIs and the data they transmit. We might be worried about unauthorized access, an adverse reaction to a distributed denial-of-service (DDoS) — more than one API has fallen over and left the underlying system wide open and completely insecure — or other malicious attacks.

There's an art to securing APIs; a light touch and a delicate combination of technical and organizational skills are required to do it right.

On the technical side, we’re looking at measures such as authentication and authorization, encryption, automated testing, and monitoring. On the organizational side, you need to know exactly who on the org chart the API was designed to serve, and tailor access accordingly. For external APIs, you need to know how much data should be available to the outside world and how that data needs to be curated and presented.

How Are APIs Protected?

There's a sane order of operations when you're trying to secure your company's APIs.

First, find and catalog every API. The number of companies that actually do this and keep their API inventory up to date is small indeed. Developer convenience, rapid website development, and the increasing push toward federated services all contribute to mystery APIs popping up out of the blue without any kind of compulsory registration structure in place.

To avoid this kind of API creep, every single one of them should be registered centrally with the following information:

All of this information goes into a repository run by the cybersecurity team.

Second, set up security and performance automation for every API. This is why you asked for all of that information, and this is how you keep everything secure. Using the data provided by the developers (and DevOps team, the Web team, etc.), the cybersecurity and/or testing team can put together automation that tests the API regularly.

Functional tests are important because they make sure that everything is working as expected. Nonfunctional tests are important because they probe the reliability and security of the API. Remember that APIs must fail securely. It isn't enough to know that one has fallen over — you need to know the consequences of that failure.

Finally, add the API to the normal threat prevention suite. If any of the tools or packages used to build the API are found to be buggy, you need to know. If any of the protocols that it uses are deemed insecure when you do detect trouble, you need to have the team shut the APIs down until they can be examined and rebuilt.

Taking these actions once is great; creating a programming and security culture that allows you to maintain fully cataloged and documented APIs is the long-term goal.

Specific API Behaviors to Note

When pen testing and securing an API, some techniques are more useful than others.

There needs to be some level of authentication with APIs that are designed for a specific user base. However, this can get complex. Federation is one issue that you need to deal with, determining which central identification and authentication servers you'll accept. You might want to have two-factor authentication for particularly sensitive or powerful APIs. And, of course, authentication itself isn't necessarily a password these days; biometrics is a valid way to wall off an API. To make a long story short: Apply the standards that you find reasonable and test the limitations that you've set on a regular basis.

Finally, encryption and digital signatures need to be part of the conversation. If it's on the Web, then we're talking about TLS at minimum. (Repeat the mantra: We don't REST without TLS!) Other interfaces also need encryption, so pick your protocols wisely. Remember that static information, be it a database or a pool of files somewhere, also needs to be encrypted. No flat text files anywhere, no matter how "innocent"; salt and hash should be the standard. And checksums are a must when providing or receiving files that are known entities (size, contents, etc.).

Finally, key management can be difficult to get right. Don't expect every DevOps person to have perfect digital key implementation when a decent portion of the cybersecurity folks are half-assing it themselves. When in doubt, go back to the OWASP Cheat Sheet! That's what it's there for.

Responding to an API Attack

The cardinal rule is: If your API is going to fail, pinch off access. Under no circumstance should services fail in an open or accessible state. Remember to rate-limit and keep error messages short and generic. Don't worry about honey pots or API jails — worry about survival.

Custom-crafted API attacks on an individual basis need to be treated like any other breach attempt. Whether you caught the attempt yourself or via AI/ML analysis, follow your SOP. Don't cut corners because it's "just" an API.

API security separates the mediocre CISO who focuses solely on infrastructure from the masterful CISO who addresses actual business threats and ensures survivability. Create a system for API security, create reusable interface testing automation, and keep your API inventory up to date.