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 failures in security implementations get API project stakeholders on alert but also regulations like PSD2 have been kick starting initiatives to standardize security implementations. Questions around counter measures and best practices in API security are now even getting attention from top level management, due to the dramatic impact a security breach might potentially have on the company profitability and reputation.
A recent study by Ovum revealed that 87% of the interviewed audience were running an API Security Gateway, often part of a larger API Management platform such as Axway, IBM, CA, Google Apigee, to only mention the market leaders. So actually technology seems to be in place to protect those services against attacks.
If we look into some bad examples we can take away a few tips and basic things which can be taken into account when implementing APIs.
REST API security risk #1: HTTPS protected API without any authentication
Providing an API using HTTPS is familiar to most developers already. But using an API not having any authentication for personalized services can be tricky as the Nissan Leaf Example tells us. Their API used a Vehicle Number as identifier to allow actions like turning on the AC or reading the cars 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 it) 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
By failure of an Android App, the National Weather Service had to shut down the 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 can not 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 having implemented API keys or OAuth help identify the root cause more easily.
REST API security risk #3: unprotected identity and keys
An attack to Buffer occurred in 2013 where tokens and keys were stolen resulting in hackers being able to send spam into social media networks using accounts using Buffer. OAuth / OpenID Connect are used a lot to grant access to services on behalf of he 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 actually did helped understanding 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.
REST API security #4: 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 view. Tools like Charles Proxy or Fiddler make it even easier to listen into the connection between the mobile App and the API. A correct use of HTTPS (see below) and if needed payload encryption can help mitigate the risk of exposure.
REST API security risk #5: incorrect use of HTTPS
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
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 easy to copy. Even if HTTPS is used correctly (see above), it can be sniffed. A good way to go around this is the use of 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 go further by using two keys:
- Secret Key ID to perform HMAC signing (with detection of replay attacks)
- Access Key ID to identify the client
REST API security risk #7: logic and security in the wrong place
Last but not least, security and implementation need to be in the right place. Looking at this example from Dominos App which allowed to fake a payment shows that it’s a good practice to put critical logic like payments or approvals into a secure place which is usually not the client app.
Scared? I hope not because there are tools and procedures available to solve these issues. API Gateways and API Management systems provide protection against:
- Unauthorized Access
- Parameter manipulation and Data harvesting
- Network eaves dropping
- Disclosure of sensitive customer data
- Message replay
- Virus insertion
but also help you drive your digital strategy efficiently.