What with the rapid growth of the API economy, more sensitive data is shared through APIs than ever before. As a natural consequence of this, there are severe stakes around API security, and they’re only rising.

While it’s easy to overlook the importance of security in a brand-new API — especially if that API is only used internally or by selected partners — you ought to secure all APIs early-on. In this article, we’ll look at some of the basics of painlessly securing a new API, from thinking like a bad guy to employing established tools and standards.

Three Guiding Principles for API Security

Effective API security starts with a few axiomatic best practices, which significantly reduce the potential for an attack with little effort. According to Keith, they are:

1. Only expose the interfaces you need. An easy way to limit your API’s attack surface is by exposing only the interfaces you actually need. Every new endpoint you add represents a potential attack vector, so always avoid doing so superfluously.
2. Only collect and share the data you need. Assuming an attacker succeeds in cracking your API, what data will they gain access to? The answer, of course, is the data you collect and/or share (depending on the exploit). As a result, you should endeavor only to collect and share data when necessary. Keith provides an excellent example: if you accept a credit card number, there are very few reasons ever to expose that information.
3. Only grant access to the people and systems you need. We’ve covered the what, but the who is equally important in API security. By sharing data (and functionality) only with those who need it, you drastically limit the number of potential attackers.

Think Like a Bad Guy

Another security suggestion Keith offers is to think like a bad guy. He proposes reverse-engineering your API from an attacker’s perspective — in other words, actively looking for ways to attack it.

Since there are likely thousands of ways to exploit an API, this can take some serious creativity. As a result, he recommends you start by reading about others’ security breaches (especially your competitors’), and seeing whether the same issues might arise in your own API.

Another option is to speak to your legal teams, whose primary goal is to protect the organization. Although they might not be API security experts, they can look into where you stand from a compliance perspective — which is always a good starting point — as well as a broader liability perspective. Keith jokes that if nothing else, you ought to take them out to lunch (so they owe you one)!

Next, you can speak to fellow API developers about their security horror stories. Chances are, each of them has experienced a serious security oversight first-hand. Finally, look through all of your API’s endpoints one-by-one, asking yourself, “how could this be used against us?”

Tools and Standards

Next up in your API security strategy are tools and standards. That’s right: doing everything yourself is not the right approach! Instead, rely on tools and standards which are built by dedicated security experts, or have been developed collaboratively over many years (or even decades).

Tools: The API Gateway

It should come as no surprise that Keith recommends using some kind of API gateway or management platform. These platforms usually cover a wide range of API ownership issues, from development to performance, but most importantly, they help you manage interface (which resources/methods/objects/fields are exposed) and access (who has access and how they authenticate).

Standards: Encryption and Authentication

Similarly, you should rely on standardized approaches to encryption and authentication. There’s a whole host of bulletproof encryption methods out there, and very little incentive to build your own. As for authentication, OAuth 2.0 with OpenID Connect is the de facto standard, and for a good reason.

The Importance of Time

From Keith’s perspective, the biggest asset an attacker can have is time. If an exploit is left undetected over the course of days, weeks, months, or even years, the number (and gravity) of potential consequences multiply greatly. And that’s not just because more data is leaked: an exploit in one system can enable further attacks elsewhere.

To counter this, integrate security checks into your existing processes. Ensure that your API is constantly being monitored, with both automatic and manual checks for suspicious activity.

Final Thoughts

Instead of summarizing his main points, Keith ends the presentation with a few crucial questions. As you build your API security strategy, ask yourself:

• What’s the worst thing someone can do with our API?
• What happens if our competitors get our data?
• What data do we need to collect, and what do we need to expose?
• Who are your users now, and who will they be in a week, month, or year?
• How are we monitoring when things go wrong?