API Rate Limiting

In a frontend and backend, rate limiting is a great way to reduce the load, provide security and maintain performance on the backend API. Rate limiting is also a way to safeguard against DoS (denial of service) attacks that spam a server with unlimited requests and also prevent the abuse of an API.

One common example of Rate Limiting would be the HTTP 429 Too Many Requests Response. This is usually due to exceeding too many requests in a given amount of time.

# What is Rate Limiting?

Rate limiting is a strategy for limiting network traffic. It puts a cap on how often someone can repeat an action within a certain timeframe — for instance, trying to log in to an account or sending OTP. Rate limiting can help stop certain kinds of malicious bot activity. It can also reduce strain on web servers.

We can implement rate-limiting on API in many ways such as - IP based rate limiting, Device id based rate limiting, User token-based Rate limiting, and many more.

# How do social media platforms like Twitter and Instagram use rate-limiting?

Social media platform rate limiting is basically just API rate limiting. Any third-party application that integrates Twitter, for instance, can only refresh to look for new tweets or messages a certain amount of times per hour. Instagram has similar limits for third-party apps. This is why users may occasionally encounter a rate limit exceeded messages.

These limits typically don’t apply to users who are using the social media platform directly.

# User token based ratelimiting

So, here we are gonna discuss about user token-based rate-limiting, to rate limit using user token, we can implement X-UserToken header in the request in which user-related data such as DeviceId, IP address, Account type, subscription info, etc can be sent in base64 encoded format and then that UserToken value is used to create an auth header to check the integrity of the X-UserToken.

To create auth header we can use the “Hmac sha256" algorithm to encode the X-UserToken using a secret key, so that when the token is changed by the user or attacker, then the auth header will give response “token is tempered” as the user-provided token will not match the Hmac created from the original user token.

After which the rate-limiting can be set based on X-UserToken, timestamp and phone number to check the count of OTP sent on the same phone number to block that number temporarily after 10 OTP’s are sent and if the different phone number is used to send OTP from the same user token it does not block that new number.

These tactics can go hand in hand and are implemented to smooth over traffic spikes so that the servers can run properly for other users. They allow your app to become more secure and scalable.