API Protection

Building an API is easy—there’s an abundance of languages and frameworks that let you spin one up quickly. However, making a great API takes a bit more effort.

Protection is one important aspect of what makes an API great. Let’s take a look at three essential ways to protect your API.

Rate Limiting

The first thing I enforce in my API endpoints is rate limiting. If someone is spamming your API, you want to minimize the compute resources they consume on your servers.

There’s nothing wrong with doing authorization and input validation first, but it means spammers are getting more processing time or even a free database connection (if you’re using sessions).

You don’t need anything fancy to implement rate limiting efficiently. If your API runs on a persistent server, you can manage it using in-memory storage. If your API is serverless, you’ll need a persistent store like Redis.

Input Validation

If your endpoint accepts user input—such as path parameters, query parameters, a JSON body, or form data—you need to validate it.

This should be self-explanatory. Lack of input validation can lead to unhandled errors or, worse, unexpected behavior.

This can be as simple as a few if statements, but I prefer using validation libraries like Zod.

Authorization

After rate limiting and input validation, I enforce authorization. Naturally, you can skip this step if you intend the endpoint to be publicly accessible.

I prefer to handle authorization last, especially when using database sessions. This way, unauthorized requests never take up a database connection or get a free read (and therefore compute resources).

This becomes even more important when using a third-party authentication provider, as they may have their own rate limits.

Conclusion

These are the three essential protections every API should have. Without them, you’re leaving room for abuse and unnecessary headaches.

P.S. Don’t forget to leverage asynchronous operations where possible! You’d be surprised how many tasks can run concurrently.