---
It is always better to lead with example rather than to preach merely by words, this article does the same. We will share our experience, the way we secured our REST APIs. This article is an extension to the previous one Are your Rest APIs safe(link). As we had promised we are back with an illustration based on our experience with a sample, that will help you develop an approach to secure your APIs. In the previous post we had discussed elaborately about the different threats that a REST API can face. We had gone over what each attack means and some of its widely accepted solutions.

In this post we will be jumping between our experience and a sample API. To set the baselines of both correctly -
We will be sharing our experience that we had with a purely stateless system. We did not use any user model or database for that system.
The sample API :
This API is used to generate salary slips for the employees in the system.
REST API details:
URL - /generate/salaryslip
Method - POST
Request header -
{
"Content-Type": "application/json"
}

Request payload -
{
"emp_id": "01234",
"emp_code": "ENG",
"emp_name": "John Doe",
"emp_grade": "7.1",
"working_days": 24
}

With the baselines set we would now dive deep into the threats and an approach for remediation. As we have discussed earlier it would be very difficult to put up a single solution that can remediate all the attacks and thus we have broken down the approach into sections that will follow.

1. Injection attack:
The main intention of any attacker when he is trying an injection attack is inserting a malicious piece of code that can be executed on the server. Thus, data integrity is what needs to be maintained. In our case to check for the payload integrity we calculate the hash of the entire request payload by some secret which is a combination of secret key and timestamp.The key and the hash function is pre decided and known to both the client and the server. The hash value and the timestamp are sent over as request headers of the REST API. On receiving the request on the server, the server calculates the hash of the received request payload and matches it with the hash received in the request header. If the hash values do not match the request should be dropped without processing further.

Below are the steps to generate hash -
First we are converting request payload to string and encoding it with utf-8 encoding
Generate hash say hashclient with the help of key or secret which is known to both server and client, decide algorithm to use such as HMAC or ECDSA and request payload string
Add this hash in your request header as one of the header
At server you can follow same steps as that of client side to create hash say hashserver
Compare hashclient and hashserver
If both the hash are same then server will proceed with the request otherwise drop the request

2. Broken Authentication and Authorization:

As we said we do not have any user model and database in place for our system. But in our case there is another server say Serveruser which is hosting all the user data. This Serveruser creates unique tokens for every user with some expiry time associated with it. So our server is accepting this token with each request from client asks Serveruser to validate it. If Serveruer says the user is authenticated and authorized for the operation we proceed with the request. Also if token is expired our client will prompt user and ask for valid credentials to generate new token. This new token will be passed with subsequent requests.

3. Exposure of request data/Man In The Middle (MITM) attack:
Here data at rest was not our concern since we dont store any users data. But to secure data in motion we ensured data tansfer to and from our client to server along with to and from our server to ABC server if through secure network. This is achieved by using HTTPS channel secured by TLS protocol instead of simple HTTP.

4. Replay attack:
To avoid such attacks we keep a time delay constant at our server say 300 seconds.
Steps to follow are:
Now we will add client utc time in request header say timeclient.
Server will check the difference between timeclient with its own time.
If the difference is greater than the time delay constant then server will drop the request otherwise proceed the request further.

To set time delay constant we should consider some factors such as network latency, processing capabilities otherwise we can end up with dropping valid requests.

5. Denial of Service (DoS and DDoS):

For this type of attack we used request ratelimit technique. As our server is written in python using Django framework, we used django ratelimiter utility. This ratelimiter is applied for every API which checks how many times request being hit and limits its use based on users identity and ip address of the machine being used for request.

This is our approach to secure all our stateless REST APIs to avoid and minimize the threats. We hope this will act as a guide to readers of this artical for designing approaches/techniques to secure their REST API.