Test & Protect Your API: Practical Tips for API Security

APIs are a critical aspect of business delivery in the digital world – they connect mobile applications, the Internet of Things, and providing the fabric that links internal business processes. Considering the pervasiveness and importance of APIs, it stands to reason that we should ensure that they are secure – after all, we would not want hackers to use an API to access to information housed in your mobile app, devices in your home, or processes that could cripple your business if they were compromised.

And we have yet to catch up to the API Security learning curve:  SmartBear and Axway recently conducted a webinar on API protection, and surveyed attendees on their organization’s approach to API security:


The disparity is clear: 56% of webinar attendees responded that API security is “very important,” and yet only 12% are doing extensive security testing.

In this post, we’re going to illustrate the importance of API Security using real-world examples of API security breaches, and then provide practical examples of how to avoid security threats in your own API.

API Security Breaches: It Happened to Them, It Could Happen to You.

API security is not just a theoretical concept – we’ve seen it time and time again in the wild. Here are a few examples of API breaches and how they occurred.


You’ve probably heard of the recent SSL and open SSL vulnerabilities - from Shellshock onward, several vulnerabilities have required patching. In the case of Yahoo, they responded to these vulnerabilities by releasing patches for their web properties: the servers serving as Yahoo Finance, Yahoo Sports, and so on. But their API properties were left without that update and protection, and as a result hackers were able to access three Yahoo Sports API servers. It's important to really think of APIs as a first class citizen in the connected world, and tailor your security strategy accordingly.


SnapChat suffered another high-profile API hack last year. SnapChat has an API that allows you to look up and see if another user has an account on SnapChat, enabling users to locate phone contacts, add them to their friend’s list and communicate with them from within the application. That API didn't have adequate security protections in place to avoid certain usage behaviors. For example, it was possible to write a script that checked every possible phone number to determine if it existed in SnapChat. Thus, it was possible to retrieve phone numbers and other personal information about SnapChat users. This exposed weren’t, for example, API throttling & quotas in place.

The International Revenue Service

The IRS has an API called the Get Transcripts API, allowing the procurement of tax transcripts. Again, the API was not protected against certain unwanted user behaviors and as a result, information was obtainable through this API. This IRS data leak impacted upwards of 100,000 citizens. When you produce an API, it's important to ensure that there are API policies in place to guarantee that the API is being used in the way you want it to be used, so it doesn't end up being the subject of a similar breach.


Buffer is an application that allows Twitter users to queue up tweets in advance requiring that they give Buffer the authorization to send tweets on their behalf, in this case using OAuth. But what happens if the service you authorized to use your twitter account is compromised? It's still calling the API on your behalf, and in many cases will send illegitimate content from your account. In this case, the OAuth credentials were not properly managed, and the authorization keys fell into the wrong hands, allowing API access.

We’ve already dug into several examples of API security breaches in the wild – this is just the tip of the iceberg, and if it happened to them, it’s equally possible that it could happen to you.

Practical Tips to Avoid API Hacks

API Security Testing – Think Like a Hacker

To avoid seeing your name in the news in the worst way, create a security testing plan.

  • Step 1: think like an API hacker. API providers have a tendency to look at APIs from the inside out – they built them, so they understand them. But think from the outside in: what information is a hacker looking for? A hacker is looking how to get in - the more they know about your API surface, the more they know about avenues to breach your API.
  • Step 2: look for vulnerabilities in your API. OWASP.org is a great resource, listing the top API hacks to watch out for. Run API security scans for each of those top hacks.
  • Step 3: when you locate vulnerabilities in your API, run API security scans, automating and repeat the most important ones as determined by the business use of your API. You're constantly enhancing and modifying your API, so you want to prevent additional security breaches.
  • Step 4: if you do experience a breach or a hack as a result of a vulnerability in your API it’s important to respond very quickly. Pay attention, listen to your audience as they tell you when they've found an issue, and resolve the error with speed.

Detect Insecure API Calls with Sniffers

Insecurity can proliferate in mobile apps – these applications often reference several APIs, and if any of these APIs are insecure, then the information obtained by the app is compromised. One practical method to locate mobile app security issues is to run a sniffer to analyze the call-home traffic from the mobile app. Often times you’d be surprised at the information passing back to the internet: confidential information, passwords, you name it.

Balance API Security with Ease-of-Use

To be frank, API security can often be complicated to manage. Some standards that were used five-plus years ago were disastrously overcomplicated and cumbersome, creating very large messages - but at least there were standards for how credentials were put into messages. With REST APIs, often API keys are sometimes written into headers, resulting in systems that are vulnerable to sniffing, finding the keys, replaying the messages, and thus they are vulnerable to replay attacks. This creates a tricky dichotomy - we want people to understand our APIs so that they can easily consume them, but this cannot come at the risk of exposing your API to hacking.

So how do you do this? Amazon is a good example - If you've coded against the Amazon API, you'll notice that there are two keys. One of the keys is not stamped with their request. That's the secret key ID, used to do signings, HMAC, digest and there's a timestamp to ensure that the message can't simply be taken and replayed. There's also an access key which is what's sent with the client. It's sophisticated and secure.

Quotas & Throttling

Let’s go back to the SnapChat example that we mentioned earlier, in which a nefarious user could write scripts that sequentially search every possible phone number to call the SnapChat API and retrieve user information. Clearly, there weren't quotas or throttling in place, which are an important part of API security. If you produce an API that is used by a mobile application or particularly rich web client, then you will likely understand the user behavior of those applications clients. If a typical user calls the API once or twice per minute, it’s unlikely that you will encounter several-thousand requests per second at any given time. A behavioral change such as this is an indication that your API is being misused.

Throttling also protects APIs from Denials of Service and from spikes. It’s possible to implement sophisticated throttling rules to redirect overflows of traffic to backup APIs to mitigate these issues.

Treat Your API Gateway as Your Enforcer

The API gateway is the core piece of infrastructure that enforces API security. Unlike with traditional firewalls, with APIs security requires analyzing messages, tokens and parameters, all in an intelligent way. The API gateway checks authorization, then checks parameters and the content sent by authorized users. It then ensures that when logs are written that they're redacted, that the customer data isn't in the logs, and does not get written into storage. And it accomplishes these steps in the proper order.

When configuring throttling rules, usage of API keys or OAuth, the API gateway acts as the enforcement point. This is the traffic cop, ensuring that the right users are allowed access, and the wrong ones are being blocked. An API gateway can be used either for incoming requests, coming into your APIs. The API gateway allows you to encrypt parts of the message or redact confidential information, then meter, control, and analyze how your APIs are being used.

So much can be done with an API gateway, but its main benefit is moving security from the application to your organizational infrastructure, allowing you to treat the security of your application and API like a first-class citizen.

The content in this blog post originated in a co-presented webinar with Axway and SmartBear. If you’d like to view this webinar in its entirety, including a live demonstration of the Axway 5 API Management Suite and Ready! API Secure Pro, you can view the webinar here: http://www2.smartbear.com/outbound-Ready-API-Axway-Security-Webinar-Replay.html