Because they power applications used by hundreds, thousands, and even millions of people, security is hugely important when creating APIs. Despite this, perhaps due to their now outdated reputation as niche products “just for techies,” there can be a bit of an air of complacency around API security.

In the past, we’ve written broadly about the subject and also covered a few specific cases, such as API security for banking. What we’ve dealt with less often, however, is how to address the myriad security challenges that API developers face.

Speaking at our 2018 Austin API Summit, Andrew Slivker of Nevatech covered a few of the potential pitfalls of API security as well as how an API gateway can go a long way towards addressing them.

Current API Security Models

In 2018, access to APIs is increasingly fragmented in terms of where they’re being accessed and the devices being used to access them. Think, for example, of how people in 2018 might use Google Home or Alexa to call an Uber or trigger a Spotify playlist; that’s a far cry from the original incarnations of those apps.

Slivker makes a key point when he says that “even simple interactions can be complicated by different environments such as on-premise, cloud, and hybrid access.” This feeling of fragmentation is especially problematic for many APIs that work with sensitive data. It’s no surprise that they’re a major target for cybercriminals, foreign actors, and the like.

But there is some good news: security standards exist to prevent such exploits. Slivker says that “technically speaking, especially for REST APIs, there are only a few security models that are considered to be standard, i.e. well-defined by industry specifications.” He provides the following examples:

• Username/Password (basic authentication)
• X.509 certifications (single-sided or mutual)
• Kerberos/NTLM
• OAuth
• Custom (API keys)

This means, as Slivker highlights, that other developers using the API will understand what basic authentication means without having to do any additional research: “It says it all. The developer wouldn’t have to know anything else about the security model of my API.”

Maybe it’s worth pointing out right off the bat that a somewhat limited number of approaches to API security isn’t necessarily a bad thing; it means that choosing an appropriate solution is less daunting than if there were, say, 20+ viable standards on the market.

But “limited” isn’t the same as “one”, which means that getting security models to talk to each other can be problematic. The best solution to this issue, in Slivker’s view, is using an API gateway.

The Gateway To Success?

Chris Richardson of Eventuate, Inc. describes an API gateway as “a server that is the single entry point into the system…[it] encapsulates the internal system architecture and provides an API that is tailored to each client. It might have other responsibilities such as authentication, monitoring, load balancing, caching, request shaping and management, and static response handling.”

Slivker says that whether a gateway is located on-premise, in the cloud or serving as a DMZ, it can “encapsulate API security challenges, relating to both inbound and outbound activity, inside itself.”

He adds that “the API gateway is a middleman that sits between an API consumer and the API itself and effectively acts a broker,” which is another neat summary of why they’re useful for security; imagine a bouncer having to guard just one door instead of trying to keep an eye on fifty.

It also goes towards explaining why one area in which API gateways shine is mediation; they allow an API to expect, and handle, any type of security model on the inbound side. Security models can be the same on both inbound and outbound sides or they can be different, which lends an API much more flexibility.

Writing for nginx, Richardson uses Netflix as a case study of why API gateways can be so powerful:

“The Netflix streaming service is available on hundreds of different kinds of devices including televisions, set‑top boxes, smartphones, gaming systems, tablets, etc. Initially, Netflix attempted to provide a one‑size‑fits‑all API for their streaming service. However, they discovered that it didn’t work well because of the diverse range of devices and their unique needs. Today, they use an API Gateway that provides an API tailored for each device by running device‑specific adapter code. An adapter typically handles each request by invoking on average six to seven backend services.”

Netflix may have shuttered their public API, but they’re still highly regarded in the API space and are a great example of a company that needs to be as flexible as possible because of the number of ways the service can be accessed.

API Security and Data Breaches

Slivker talks about how API management includes everything from API catalogs and accessing metadata (e.g. OpenAPI Spec) through to finding documentation, sample files, and more. But, as he points out, monitoring and security also represent a huge part of successful API management.

To borrow a phrase from Slivker, “security that doesn’t have trails is already half-broken.” API gateways add value in that they bring as much of the security process as possible under your control and make it easier to observe.

As well as protecting your API by placing a gateway in front of it, you can also use an API gateway for consuming an** external API**. “But why would you want to do that?” you ask. The simple answer is that it can help protect you if and when other companies you deal with fail to take appropriate protective measures.

When we think of data breaches, most of us think of companies/sites like content aggregator Reddit, Equifax or electrical giant Dixons Carphone. We might not, however, associate them with APIs. Well, maybe we should.

In 2017, it was revealed that an unauthorized API endpoint was to blame for Panera Bread leaking up to 37 million customer records. Meanwhile, Salesforce admitted just weeks ago that their customer data may have been improperly shared due to an API error. In the age of GDPR and other data protection law overhauls, API errors and leaky endpoints could end up being incredibly costly mistakes.

In a nutshell, security is about authentication and authorization. Slivker argues that effective implementation of a gateway “should be able to absorb all of that, so back-end services don’t have to deal with authorization anymore.” This simplifies access rule configuration and, potentially, dealing with complex authorization logic.

Final Thoughts

API developers often put features and uptime above security. That’s not necessarily reckless behavior, but a result of limited time and resources. No one will use an API that only has 73% uptime or a very limited number of functions, thereby those concerns are privileged.

While insufficient security is much less obvious to the naked eye, large data breaches continue to make the dark outcomes impossible to ignore. The DevSecOps approach is evidence of a growing concern to counteract poor security.

According to Slivker, embracing third parties for a proactive security measure means less time and less code:

“Your API security challenges can and should be delegated to API management infrastructure because [it means] you don’t have to write any code, it’s all about configuration”

Jason Macy, of API security management provider Forum Systems, makes the point that “just as you wouldn’t trust your applications to provide real firewall or malware protection, you shouldn’t expect your API management platforms to provide real API security protection.”

Think critically about API security throughout your lifecycle, and with each tool you add to your stack. While an API gateway may not be able to address every single API security concern you have, it represents a very good start.