How to fix: Lack of resources and Rate Limiting

Context

Developing an API is already a complicated task. Therefore, it is normal for most teams to focus on working efficiently and forget about the security of what they develop.

In the early stages of a project, working this way makes sense because the focus is on speed, whether it's getting an MVP ready or hitting a big launch date on time. However, as companies get bigger, they become targets for cybercriminals. Therefore, as a company grows, it must increasingly focus on secure development, thus replacing efficient development.

A single cyber attack can cost a large company hundreds of thousands of dollars in loss. Furthermore, after an event like this, reputation is the most difficult thing to recover.

For this reason, it is best that teams learn to develop safely at the earliest possible stages. In Strike, we have developed a series of articles with which you can learn that skill. Not only that, but we have also created an ebook that you can use as a checklist every time you want to develop an API. You can find it at this link: https://discover.strike.sh/api-guide

In this article, we will specifically deal with one of the TOP 10 problems that can arise when developing an API. Discover how to deal with: Lack of resources and Rate Limiting

Lack of resources and Rate Limiting

Description

The application does not properly set limits for the resources that can be requested.

Checklist to know if your API is vulnerable:

• Missing execution timeouts limits. Missing max allocable memory limits.
• Missing number of file descriptors limits.
• Missing number of processes limits.
• Missing request payload size (e.g. uploads) limits. Missing number of requests per client / resource limits.
• Missing number of records per page to return in a single request response limits.

Example Attack Scenario #1

An attacker uploads a large image by issuing a POST request to /api/v1/ profilepicture. When the upload is complete, the API creates an avatar for the user. Due to the size of the uploaded image, available memory is exhausted during the creation of thumbnails and the API becomes unresponsive.

Example Attack Scenario #2

We have an application that contains the users' list on a UI with a limit of 200 users per page. The users' list is retrieved from the server using the following query: /api/users?page=1&size=100. An attacker changes the size parameter to 200 000, causing performance issues on the database. Meanwhile, the API becomes unresponsive and is unable to handle further requests from this or any other clients (aka DoS). The same scenario might be used to provoke Integer Overflow or Bu!er Overflow errors.

Checklist to prevent

• For sensitive operations such as login or password reset, implement rate limits by API method (e.g. authentication), client (e.g. IP address), property (e.g. username).
• Notify the client when the limit is exceeded by providing the limit number and the time at which the limit will be reset.

Conclusion

We hope you found this information useful! This is just one of many articles that we are writing to spread as much information as we can to improve the skill of developing securely of developers all around the globe. If you found this article useful, feel free to discover more on our blog.

Also, our CEO created an impressive guide on how to develop APIs securely for internal use. However, we are committed to making cybersecurity accessible, so we are releasing it for free. Discover the full-length, 77-page guide, just a click away: https://discover.strike.sh/api-guide