In general, a web application should use some type of rate limiter to block rogue clients from overloading your servers. Typically, this is done by checking the IP of the non-logged in users and session key of the logged in users. For example, you may decide:
- to allow only 20 requests per second from the same IP for non-logged in users.
- to allow 5 requests per second from the same session-key for the logged in users.
However, there are certain APIs which are either expensive (for example, APIs which send SMS) or very resource hungry (for example, an API which kicks off a batch process.) For these APIs, it’s critical to have specific rate limits in the place. So rather than depending on generic middleware filters, it’s important to add specific rate limits for these APIs. Here are some things you can implement:
For APIs which send Send OTP, forgot password email, etc
- These APIs are called without a session key, but these are sent to a specific number or email.
- Allow only 2 API calls per minute to send OTP to the same number or email.
- Allow a maximum of 5 (or some other sensible value which makes sense for your use case) API calls send OTP to the same number or email.
- For email or number verification, if the email or the number is already verified then don’t send the SMS or email again. Just return a quick error message.
- Also in case of register APIs, there should be a field in the API which prevents the verification number or email from going. This helps in automation testing. Here note that if this field is set then DO NOT mark the user as verified in the DB. Only the email shouldn’t go. Otherwise, hackers will use this field to bypass the verification.
- If for automation testing you need to disable verification, then it must be a backend setting which allows requests coming from a few specific IPs are permitted to register users without verification.
For APIs which send SMS or email from a request from a logged in user
- An example of this, “An appointment was booked for you” type of message. These kinds of messages will be triggered when a logged in customer books an appointment for a service provider on the system.
- For such cases, we can limit the API usage by the session key of the user. In these cases, you need to add sensible limits. For example, by following the proper booking flow a user should not be able to book more than 2 appointments in 1 minute. So you can add a rate limit for the same.
An important thing to remember: These parameters like “2” appointments in “1” minute, should be configurable via application config. So that they can be changed quickly as required.
If your project uses Redis, then to store rate limiting stats you should use Redis.
Similar limitations should be placed on all APIs which kick off a batch job (for example, sending mass emails or SMS) or deal with any aspect of payment processing.
APIs that don’t deal directly with credit card, but are still monetary in nature, for example, some operation that deducts wallet balance or credits, should also have a stringent rate limit in place.
Hope this short technical read gave you a better knowledge of using APIs efficiently.
Author's Bio:
Pritam Barhate, with an experience of 14+ years in technology, heads Technology Innovation at Mobisoft Infotech. He has a rich experience in design and development. He has been a consultant for a variety of industries and startups. At Mobisoft Infotech, he primarily focuses on technology resources and develops the most advanced solutions.
