REST API security

Securing your REST API

The security of your REST API is an integral part of any development project and also for REST APIs. Often we deal with medical, financial, personal or other kinds of sensitive data and securing them is crucial for both your users and clients. There are many ways to protect API and in this article, we want to talk about some of the strategies to make it less vulnerable.

If your API is consumed by your client application, you have to assume, that it is public and this means that it becomes a target to hackers who can break your system or steal important information about your clients and users. With the growing adoption of cloud, mobile, and hybrid environments the risks are increasing.

Authentication and Authorization

There are many ways to authenticate consumers of your API, and to make it more secure it is recommended to use multi-factor authentication where two or more pieces of information users need to provide in order to consume your endpoints. For APIs, developers often delegate authentication to an external process in order to get some kind of access token. Here in our company, we are using a protocol called OAuth2. This protocol doesn’t share password data but instead uses these access tokens to prove an identity between consumers and service providers. It allows us to approve one application interacting with another on your behalf without giving away your password.

Authentication alone is not enough, in fact, there should be an authorization step to determine what resources the authenticated user has access to. The most common way we are dealing with authorization is role-based access control (RBAC). With this authorization strategy, we can be sure that authenticated users cannot call any of the endpoints which are meant to be used by web site administrators. Every user has its role and for every endpoint there are defined roles that can call this endpoint.


Another important requirement is to encrypt the communication flow using cryptographic protocols since the request-response cycle is your API’s weakest point. Every piece of vulnerable information such API keys, passwords, and tokens should be encrypted. These cryptographic protocols translate this data into another form, or code so that only people with access to a secret key or password can read it. Encrypted data is commonly referred to as ciphertext, while unencrypted data is called plaintext. The hardest encryption to crack is most likely a combination of two or three methods, used together. Some of the most secure encryptions are AES, 3DES, and RSA.

Protect against XSS attacks

Between server and client data is sent through URL parameters or the request body and malicious users can try to send data which can cause your API to break. Cross-site scripting (XSS) attacks inject malicious JavaScript into your pages, which then runs in the browsers of your users, and can change page content, or steal information. Some of the most common attacks of this type are SQL injections. Some requests, if carefully crafted, can penetrate many layers across the infrastructure. For parameters, it is recommended not to trust any sort of input strings or objects, and always validate against a specific set of rules and expectations.

DDoS protection

To protect your server from a distributed denial-of-service (DDoS) we need to monitor incoming traffic to the website. Any traffic that isn’t legitimate is denied access, but legitimate traffic still needs to continue to filter through to the site. This would include requests per time unit, bandwidth limits, or monthly quotas. You can also add a request timestamp as HTTP custom header in API request and then compare the current timestamp to the request timestamp, and only accept the request if it is within a reasonable timeframe. In addition to this, you can use some of the protection services such as DOSarrest, F5 Networks, Imperva Incapsule etc.

Always use HTTPS

If your API endpoints allow API consumers to talk over HTTP or other non-secure protocols, you’re putting them at a big risk. Passwords, secret keys, and credit card information can easily get stolen as any ‘man in the middle’ or packet sniffer tool can read them as plain text. So, always make https the only option available. No matter how trivial an endpoint might seem, connecting over HTTP shouldn’t even be an option. TLS certificate doesn’t cost much, you can buy it for a little amount of money

Auditing and Logging

Auditing should never be skipped. Any sort of logging should be systematic and independent, and resistant to log injection attacks. Auditing is used to answer the question “Who did what?” and possibly why. There is a technical issue in that Auditing often has legal requirements. Logging is more focused on what it happening. It is simply the abstract task of recording data about events that take place in a system. By recording all the actions we provide documentary evidence of the sequence of activities that have affected at any time a specific operation, procedure or event.


After you finish implementing security measures and want to test them, there are plenty of website security tools, often referred to as penetration testing. The results from these automatic tests can be daunting, as they present a wealth of potential issues. In this case, it is important to focus on the critical issues first. Each issue reported normally comes with a good explanation of the potential problem, and some of the medium/low issues might not be a concern for your site.

These are only some of the procedures you can follow in order to make your API more secure and less vulnerable. Following these guidelines will result in a more secure and quality REST API service and a more developer-friendly REST API.