5 API Security Risks and How to Mitigate them

API Security Checks

By David Mytton,
CEO & Founder of Server Density.

Published on the 8th October, 2015.

Update 15th Oct 2015: Part 3 is here.

October is Security Month here at Server Density. To mark the occasion we’ve partnered with our friends at Detectify to create a short series of security dispatches for you.

Last week we covered some essential Website Security checks. In this second instalment, we turn our focus on API security risks.

Best of Both Worlds

Openness and security are two opposing priorities. Intelligent API design is a balancing act between the two. How do you open up your application and integrate with the outside world without presenting an attack surface that jeopardizes your security?

A good API creates possibilities, but it also creates boundaries. What follows are 5 design pitfalls you need to be aware of when securing your API.

1. Lack of TLS/SSL

Encryption at the transport layer is the first step towards secure APIs. Without the use of proper transport security, an eavesdropper will be able to read and tamper with your data (Man In The Middle attack).

Acquiring a TLS certificate is inexpensive and straightforward. We wrote about transport layer security (HTTPS) in last week’s dispatch, and we’ve also touched on it here.

2. Encryption does not imply Trust

In order for encrypted communication to commence, a web client requires an SSL certificate that needs to be validated. This validation process is not always straightforward and if not planned properly it creates potential certificate validation loopholes.

If exploited, this vulnerability allows hackers to use fake certificates and traffic interception tools to obtain usernames, passwords, API keys and—most crucially—steal user data.

Here is how it works. An attacker forges a malicious certificate—anyone with an internet connection can issue ”self-signed” SSL certificates—and gets the clients to trust it. For example, a bogus certificate could have a name that closely resembles a trusted name, making it harder for an unsuspecting web client to tell the difference. Once this “weak validation” takes place the attacker gains read / write access to user data, in what is otherwise an encrypted connection. Instapaper, for example, recently discovered a certificate validation vulnerability in their app.

Make sure the clients are properly validating certificates (pertaining to the specific sites they access) with a trusted certification authority. You can also look at key pinning as an additional measure (we do this for our iOS app). This process associates a host with a particular certificate or key, so any change in those—when the client is attempting to connect—will trigger a red flag.

3. SOAP and XML

SOAP is a messaging protocol that relies on XML as its underlying data format.

The main problem with SOAP is that it’s been around for far too long. It’s also based on a complex data layer, XML. Taken together, it is a complex stack mired by numerous attack vectors including XML encryption issues, external entity attacks (XXE), and denial of service (Billion Laughs), among others.

Part of the problem is that SOAP tends to stay in production for a long time because numerous systems rely on it, and little to no effort is spent investigating the security implications of such arrangements.

The good news is, server-side vulnerabilities are just as easily spotted in a SOAP endpoint as in any other part of a web app.

So make sure you don’t overlook SOAP when auditing your security. A professional 3rd party can search for vulnerable endpoints throughout your stack and advise on how to patch them.

If you’re starting out now, you may also want to consider JSON/REST as an alternative. Over the last few years, this protocol has prevailed over the more complicated SOAP/XML for most scenarios, except perhaps legacy systems and corporate environments. We chose JSON for our server monitoring app.

4. Business Logic Flaws

Official API calls are designed to provide access to a subset of endpoints, i.e. data is supposed to be touched in a very specific manner. That’s the raison d’etre of APIs. To create structure and boundaries.

Attackers, however, can try alternative routes and calls to obtain data outside those boundaries. They do this by exploiting Business Logic Flaws in the design of the API. A few noteworthy organisations that fell victim to business logic flaws attacks are Facebook, Nokia, and Vimeo.

The best way to prevent such unintended loopholes is to manually audit your API’s. A good general practice is to expose the minimum amount of data possible (principle of least privilege).

When mission-critical information is at stake you may need the help of 3rd party experts that can help spot any loopholes. An affordable solution is to crowdsource the pentesting of APIs to companies such as BugCrowd, HackerOne, Synack or Cobalt.

5. Insecure Endpoints

API endpoints are often overlooked from a security standpoint. They live on for a long time after deployment, which makes developers and sysadmins less inclined to tinker with for fear of breaking legacy systems relying on those APIs (think enterprises, banks, etc). Endpoint hardening measures (hashes, key signing, shared secrets to name a few) are, therefore, easier to incorporate at the early stages of API development.

What’s Next

Our next security dispatch will look at some of the top server security checks you need to be aware of. To make sure you don’t miss a beat, . You should also read the other articles from our security month, including the website security checks you should be considering, and how to secure your servers.

Free eBook: Building Secure Systems

This eBook offers detailed insights on how to secure websites, APIs, Servers, and much more. Think of it as a checklist of security non-negotiables, and priorities for secure teams.

Help us speak your language. What is your primary tech stack?

What infrastructure do you currently work with?

Articles you care about. Delivered.

Help us speak your language. What is your primary tech stack?

Maybe another time