Don’t let REST API security issues keep you awake at night 

REST API security issues and concerns should no longer be keeping you awake at night when you consider how many tools and best practices we have to minimize REST API risks. With the growth of REST APIs inside enterprises, but also outside their boundaries in their ecosystem, monitoring, protecting, and preventing attacks is key, and REST API security is of paramount importance. Not only do failures in security implementations get API project stakeholders on alert, but regulations such as PSD2 have also been kick-starting initiatives to standardize security implementations.

Questions around countermeasures and best practices in API security are now even getting attention from top-level management, because of the dramatic impact a security breach might potentially have on the company’s profitability and reputation.

Software tools can help secure REST APIs, but don’t rely on tech alone

API gateways help manage security thanks to authentication, authorization, encryption, and rate-limiting features, but security can’t be relegated to technology alone. A telling study by SALT Security found most respondents rely on API gateways (54%) followed by web application firewalls (WAFs – 44%) to identify API attacks.

And yet, most feel their tools aren’t cutting it, and nearly 20% of respondents said their organizations experienced a breach resulting from insecure APIs last year. That’s because security should always be a combination of process and technology.

If you add in the fact that API complexity continues to grow, with many companies using multiple API gateways from different vendors and struggling to gain visibility into all their APIs, it’s no wonder API security has become a challenge.

Let’s look into some poor examples for a few tips and best practices when it comes to securely implementing APIs.

Ranking the top REST API security risks

In order to prevent API security risks and issues you need to first identify them. Below are the top 7 API security risks you need to consider when working to streamline processes and systems. The first is HTTPS protected API without any authentication. Learn how to prevent these issues from happening to you along with other top API pitfalls to avoid.

Discover API Security Tools and Best Practices

REST API security risk #1: HTTPS protected API without any authentication

Among REST API security issues is the risk of HTTPS protected API without any authentication. Providing an API using HTTPS is familiar to most developers already. But using an API without any authentication for personalized services can be tricky, as the Nissan Leaf Example taught us. Their API used a Vehicle Number as an identifier to allow actions like turning on the AC or reading the car’s logbook.

Unfortunately, those vehicle numbers were visible on the front window of all those cars (so if your neighbor had one, it was easy to get) and were in the same number range. This issue resulted in Nissan shutting down this interesting service due to their inability to patch the service quickly.

REST API security risk #2: No rate limiting or throttling implemented

A second REST API security issue is when there is no rate limiting or throttle implemented. Due to the failure of an Android App, the National Weather Service had to shut down its service for some time. The API was not throttled nor limited so the traffic peak directly hit the backend.

A good practice is to enforce a system-wide quota so that the backend cannot be overloaded. An even better practice is to set up an app- and/or user-based quota. This can be easily rolled out with the help of a modern API Developer Portal.

It’s also important to monitor overload situations closely and implement API keys or OAuth to help identify the root cause more easily.

REST API security risk #3: Unprotected identity and keys

A third REST API security risk is unprotected identity and keys. In a 2013 attack on marketing tool Buffer, tokens and keys were stolen, allowing hackers to send spam into social media networks using accounts that used Buffer. OAuth/ OpenID Connect is used a lot to grant access to services on behalf of the user.

These tokens give access for a longer period of time, without handing over the password of the user to the app. This is a good thing, but users are usually not aware of this and struggle to understand the difference between password change and revoking access.

The full disclosure Buffer published at the time helps to understand the topic in more detail. In a few words, if you store any kind of identity or identity token somewhere, make sure that the system and APIs are protected and monitored very carefully. This starts not only with the API itself, but also where the data is stored, backed up, etc.

Dive deeper into practical API security with the OWASP API Security Top Ten.

REST API security risk #4: Unencrypted payload

A fourth REST API security concern involves unencrypted payload. There are still some apps – even if seldom — using unencrypted connections or payloads. Listening to traffic and API calls of websites and mobile apps is actually easier than you think. In a browser, it’s just an F12 hit away showing the browser developer’s view.

Tools like Charles Proxy or Fiddler make it even easier to listen into the connection between the mobile App and the API. Correct use of HTTPS (see below) and payload encryption if needed can help mitigate the risk of exposure.

REST API security risk #5: Incorrect use of HTTPS

Incorrect use of HTTPS is the fifth REST API security risk. As explained in the previous paragraph, using HTTPS does not prevent the connection from being intercepted. To prevent this from happening, Certificate Key Pinning needs to be implemented. Especially on mobile apps, there is native mobile OS Support for protecting certificates and use of Mutual SSL. All sensitive data like end-user credentials, API Keys, etc. should be sent over this Mutual SSL connection only.

REST API security risk #6: Weak API keys

Weak API keys present another REST API security risk. API keys are a good way to identify the consuming app of an API. Unfortunately, sometimes the key is sent as part of the URL, which makes it appear in proxy logs or other places and makes it easy to copy. Even if HTTPS is used correctly (see above), it can be sniffed.

A good way to go around this is using AWS Style API Keys. Putting API Keys in the message header (which is usually not logged on public hotspots) is a good practice and Amazon even goes further by using two keys:

1. Secret Key ID to perform HMAC signing (with detection of replay attacks)
2. Access Key ID to identify the client

Sounds complicated? No, it isn’t.

REST API security risk #7: Logic and security in the wrong place

Last but not least, the final REST API security issue has to do with logic and security being in the wrong place. Security and implementation need to be in the right place.

Looking at this example from the Dominos App which allowed to fake a payment shows that it’s a good practice to put critical logic like payments or approvals in a secure place, which is usually not the client app.

Go faster with APIs thanks to the right tools and process

There’s no need to fear, because there are tools and procedures available to solve these issues. With API security best practices in place, a universal API platform is an excellent tool for bringing all your APIs into view, allowing you to discover, secure, manage, and even monetize APIs in a marketplace more easily. It can provide protection against:

• Unauthorized access
• Parameter manipulation and aata harvesting
• Network eavesdropping
• Disclosure of sensitive customer data
• Message replay
• Virus insertion

Below, William McKinney, Senior Director of Product and Solutions Marketing for Axway’s Amplify Platform, describes how an API marketplace is one of the tools that can help enforce API security best practices.

What’s more, the right API platform helps you drive your digital strategy more efficiently. An open approach lets you discover, use, and govern APIs across multiple gateways, vendors, and environments, simplifying adoption and use of APIs for optimal business value.