Why You Must Rate Limit Your Application
Intro
Ever heard the word spawning? yes, you said. But do you really know the context in which I am referring? Maybe not, but don’t worry, this is the objective of this article, to give you an insight about just how sometimes plenty can be a great problem, especially when dealing with servers and how much workload they can carry or consider levels of stress tests they can endure.
Spawning means to produce in great numbers, in the real world, great numbers can be synonymous with wealth and affluence, the larger the number, the better, say ‘’I have fleets of cars”, sounds better than one or no car however when it comes to requests, particularly to servers, plenty can be a huge problem, a problem that can lead to the death of a server if that’s a thing. We like to express in a technical way that “My server is overwhelmed by requests from this IP address”. No doubt you have heard this phrase before as an engineer or if you have been around some.
What are my saying? my point is that every time you get your server up and running say a node back-end, always remember to limit the rate of requests that may originate from a single IP address or device, a potential hacker can get you simply by spawning you or making request indefinitely that can subsequently overwhelm your server. When servers get requests more than they can process in a reasonable amount of time, they just shut down or give control to another slave node if they are set in a load-balancing environment, the behavior causes what is known as Denial of Service (DoS). It means your server is no longer in a serving state so it will deny all services required of it so to say, but I think a way to make you understand this better is to emphasize the word Dead rhetorically, it means your server is down and can not serve resources, which is the target of your attacker, to cause resource starvation where your server runs out of memory in the same way your laptop may run out of memory for running programs that don’t release resources after usage.
Why You Must Rate Limit Your App
A Server downtime may result in you losing important user data or a moment transaction that your business can not afford to lose, sometimes it’s plain ignorance of a little boy in a basement somewhere just doing things he is not sure of or misbehavior of a not so savvy user somewhere, whatever the use-case may be, still, the result can be dangerous and dire if you are a financial institution or a government agency. Hacking sometimes does not really entail a person knowing how to inject code into the database, knowing how to dork a search engine or write malware with assembly language, some attacks, for the most part, are a result of someone constantly poking your app to discover loopholes, especially back-end because it is your data they want and your recklessness may just lead them to your database and when they see vulnerabilities, they quickly take advantage, know that the most ardent hackers are patient individuals who at one point may get you if you are not careful, which is why I am trying to get you to be careful when working on that great app next time.
Prevent Attacks
DoS attacks can be prevented by rate-limiting or throttling requests coming from a client app such as preventing a user to write no more than three posts per second, Twitter does this, I think. The entire idea is that, once a request is made by a particular device, that device can never make a request again within a specified period of time. Rate limiters control the rate of traffic sent by a client device, if the number of the incoming requests exceeds the number of requests allowed within a stipulated time, all the excess calls get blocked, which rate-limiting prevents the server from getting overloaded.
Rate Limiting Algorithms
There are a few rate-limiting algorithms I’d like to mention however the focus of this article isn’t to discuss rate-limiting algorithms but on how to implement one in your node app that is, a rate limiting middleware from NPM. Follow me as I try to explain below some of the popular algorithms in plain words.
- Token Bucket where request corresponds to a token, If there are enough tokens in the bucket, take one token out for each request, and the request goes through otherwise the request is dropped.
- Leaking Bucket, this is a Token bucket with a fixed rate implemented in a FIFO way whereby requests are pulled from the queue and processed at regular intervals.
- Fixed Window Counter — Here there is a timeline that is divided into fixed time windows with a counter representing each window once the counter reaches a predefined time, incoming requests are dropped.
- Sliding Window Log — Here the system keeps track of the timestamp when a request arrives, it removes the old timestamp and adds a new timestamp.
- Sliding Window Counter — Here there is a constant number of requests that can be allowed, so long as that number is not reached, requests can come in anytime. It’s a combination of Fixed Window Counter and Sliding Window Log.
I mentioned these algorithms so you can take time out and research them well on your own since space won’t do us justice even if I want to write intensively about the processes and what goes on in each.
Rate Limit Implementation
To use the express rate limit, you have to install it using the Node Package Manager (NPM), then require it into your server to access its capabilities as shown on line 14.
To use rate limit, you have to make use of the node’s function use() which means middleware or how you use just about any of them, it has to be placed before any route because middlewares have a waterfall arrangement of top to bottom, this is to allow every request coming into the app to fall through the express rate limit and other middlewares to be filtered before getting passed on, if you placed it after a route, it won’t register that route.
Conclusion
So far, so good you can award yourself that pen tester (Penetration Test) medal for knowing one or two about security, don’t get your shoulders up high just yet, haha! kidding! but on a serious note though, you’ve got what it takes to at least beat your chest and say DDOSing attacks can never nigh thine app doorstep as you are equipped for your future apps and I must say you are in your own right to be proud mate! Hit me up in the comments section if there is anything you feel did not sit well with you in this article, we can discuss it or perhaps best learn together. I am inviting you to come on with me so that we can write together here at abstract.
Adios Amigo!