How to protect your API?

Ye Lwin Soe — Wed, 26 Jul 2023 05:38:00 GMT

Have you deployed your Websites or Mobile Apps and got hit in the face with thousands of dollar worth of bills from your SMS provider after a few months? I have. Today I’m going to share how to protect your API especially that might cost you a lot of money such as SMS OTP, Email sending API, File Upload API, etc. I’m going to talk only about “Rate Limiting” in this article while there are so many things you can do to protect your API such as preventing SQL injection, using a queue system to delay processing, etc.

Here are the steps you can take to prevent your API from attacks using rate limiting, especially from DDOS.

Rate Limiting

Rate limiting can improve your API performance as well as save you money. Here’re 4 ways you can rate limit sort by the strictness of it.

1. Request per second/minute/hour

This is the easiest and the most basic way of implementing rate limits but also the easiest to bypass. Depending on your application, you can think of a rate to limit. Very useful for API that has read/write heavy to your Database. You can use CDN such as Cloudflare to easily add such rate limiting.

2. Rate limit by IP

This is a stricter version of rate limiting, the limit is based on the IP of the user. For example, only allow 30 requests per minute from a single IP. This is very similar to Number 1 but stricter. This is harder for attackers to bypass but is still possible by using a proxy server. You can implement this using pretty much all the CDN.

3. Adding CAPTCHA

Adding a CAPTCHA is especially useful when your API call cost money, such as OTP, Email notification. The most common CAPTCHA is Google reCAPTCHA. By integrating with reCAPTCHA, google will try to verify if your client is valid so your Mobile Apps or Web Frontend will have to do the integration too. This way it’s harder for attackers to call the API without rendering your frontend properly, eliminating most of the DOS attack. This will take a little bit more time to implement but well worth it.

4. Rate limit based on Unique Identifier (ID, Email, Phone)

An example of this is, only allowing users to request OTP 3 times a day. This is the strictest rate-limiting strategy and you wouldn’t need it unless you are working for a really big company where your API users are making your API call multiple times a second such as Stock/Crypto Exchange. You probably wouldn’t need to read this article if you are working for such a company :).

Feel free to reach out if you have any questions!

REST vs GraphQL — How to choose your API architecture?

Ye Lwin Soe — Wed, 26 Jul 2023 03:26:11 GMT

Having been working on both REST and GraphQL API, I’ve accumulated a mental checklist on how to choose which one to use depending on the specific use case. I’m writing them down here for my reference as well as sharing them with you.

Things I consider while choosing API architecture

1. Is it a demo app?

If it’s a demo aka proof of concept apps or websites without any plan to make it to production, it’s easy, just go with GraphQL. It’ll make your development faster and cheaper as well.

2. Has multiple clients?

Will your Api access by multiple clients? In my case my Api were consumed by multiple Websites, mobile Apps as well as multiple kiosks, it’s a no-brainer to choose REST. Updating data or tweaking a bit of business logic that can be done in the API (backend) can take a very long time with GraphQL since you’ll have to update every client.

3. Has complex Authorisation?

If Api has a very complex Authorisation with multiple roles and different types of users, REST will be better suited as you’ll have full control of your data in the backend. With a simple Authorisation in mind, GraphQL can speed up the development process.

I hope to add more things that need to be considered to better improve decision-making. Let me know in the comment what you think.

Ye's Blog