Basic Steps for API Security
Security of microservices and APIs: the Achilles' heel of modern web applications.
APIs have become the de facto standard on software development all over the world. Every organization is creating and publishing their own APIs, even banks and e-commerce sites. API or Application Programming Interface is a set of functions or services to access and interact with an application. They are usually created when the organization wants to share their services without exposing sensitive information like database structure, for example.
You’ve probably already used APIs before, all major services and social networks have APIs such as Google, Twitter, Facebook and LinkedIn. But what about the security of those services? Are they well protected? We can all agree that after the Facebook and Cambridge Analytica scandal organizations should take a closer look at their APIs and public facing services and start taking steps to secure those. We are not saying that this case was caused by an API vulnerability, but it was mostly because of the lack of security and privacy concerns on the Facebook API that the acquisition of all that data was possible. Also Bit.ly, Snapchat and Tesla already suffered attacks on their APIs. Even RSAC, one of the biggest Security Conferences in the world, had an API vulnerability in their mobile app that leaked some users’ first and last names this year. Now let’s talk about a few basic steps that you can take today to start protecting your APIs.
First of all take into consideration three basic attributes of your API:
- Level of Exposure - Who’s going to access it? Only internal apps? Partner apps? Or Anyone on the internet?
- Information Sensitivity - Is there any sensitive data provided? Only non-user related data? Credit-card or health information?
- Change Data Ability - Is there any important data can be modified? Just GET requests? Or all the requests are enabled including DELETE?
Each of the three attributes can be classified in three levels such as: basic, intermediate, and critical. So if your API is only accessed by internal apps, you can consider that the level of exposure is basic. And if the API performs all four requests (GET, POST, PUT and DELETE) to deal with data, the change data ability attribute can be considered critical. Now let’s focus on five security attributes that your API should have.
When we talk about API Integrity we are talking about making sure that the data and transactions can only be modified by users or apps who have access to it. Even if you have a public facing API it is a good idea to keep track of who is using it and how. That can considerably reduce the attack surface of your services instead of having no control whatsoever of abuses in your API.
Some common attacks on API are usually related to injection flaws, that we mentioned in our last article, and in this case more specifically XML, JSON or SQL Injection. Make sure you are properly testing those scenarios and performing the appropriate defense mechanisms like Input Filtering and Output Encoding. Also use JSON / XML Threat Protection policies to avoid these kinds of attacks.
Also when talking about integrity, one thing that is very common for developers to miss is checking for replay attacks. Replay attacks are easily performed by many tools called Web Proxies such as Burp and ZAP. By using unique transaction IDs and checking them against previous transactions prevents the execution of this kind of attack.
Authentication and Authorization
There are many ways to authenticate users and apps into your API. The most common protocols are AppToken, OAuth2 and OpenID Connect. Unfortunately some APIs still use Basic HTTP for authentication but that’s not recommended anymore.
- AppToken - uses long strings as credentials (API Keys) and is usually used for apps and not users. Can be easily shared and reused.
- OAuth2 - Authorization protocol that provides safe access to resources. Not for authentication or federation.
- OpenID Connect - Single Sign On (SSO) protocol for the Internet. Complements OAuth2 and made for mobile.
Also make sure you have Multi-factor Authentication functionality to improve the assurance that whoever is accessing your API is really authorized to do so, even if their API credentials were compromised in some way.
Another thing to consider is how you share and store your API tokens. Never send them over email since that’s unsafe and usually unencrypted. Also don’t store them in clear text, not even on your logs. The best way to share your API Tokens is to do it on the developers site over HTTPS.
Make sure your Testers/Q&As carefully test the process of accessing and revoking the rights from the API making sure that the forwards and redirects are being done correctly.
Just like web services the availability of your API is very important. How do you expect your clients and partners to use your services, and even depend on it, if the service is not always available for them? You also have to be able to identify and prevent malicious behavior and misuse of your API by monitoring its traffic and blocking unwanted requests.
Make sure you have a payload size limit to avoid Denial of Service or Buffer Overflows attempts. Another great way to defend from these kind of attacks are Rate Limiting or Throttling and IP Filtering. But don’t think that IP Filtering is an enough form of “authentication” for your API, especially if it is a public API, that will be very hard to perform.
The first thing to protect the privacy and data of your API in transit is to use encryption. Make sure you always use TLS to encrypt the communications between your clients and your services. But TLS only is not enough, to protect against Man-in-the-Middle Attacks you also have to use techniques like HSTS and Cert Pinning. Masking sensitive information and taking the appropriate measures to avoid error handling exposures is also a good way to keep the privacy of your data protected. Reply errors with generic messages, avoiding to reveal details of the problem, but still giving the user enough information to understand it and fix it, if he has to. Never send technical details like stack traces and other internal info to the client.
Also be aware that some users and apps may try to scrape all your APIs data to clone it and try not to depend on your services anymore. If users are making repeated similar requests to your service, that’s a great indication of data scraping and should be prevented or at least hindered making them wait a few minutes before making any more requests.
Auditing is never fun to do, but that’s something every application needs. We’ve talked about this before, but it is always good to remember. Logging and Monitoring should be important aspects of your application. Make sure your developers know exactly what to log, where to log, and how long to keep those logs. Other concerns related to Auditing and Logs, according to the OWASP REST Security Cheat Sheet are:
- Write audit logs before and after security related events
- Consider logging token validation errors in order to detect attacks
- Take care of log injection attacks by sanitising log data beforehand
Also use mechanisms to avoid any kind of repudiation. If an app or a user is misbehaving on your API you can notify them with enough proof of their actions, without giving them the ability to deny what they did. And if they ignore you, you can shut them down.
Please refer to the OWASP REST Security Cheat Sheet and the OWASP API Security Project for more information on how to protect your API services. If you are using SAP on your company they have a great step-by-step tutorial on API Security Best Practices for their services. And make sure you know what applications and APIs from your organization are exposed to the internet. Check out our ImmuniWeb® Discovery service to find out how to do that. If you have any questions, don’t hesitate to ask them.