# #183 Rails 7.2 Rate limiting for Devise - Guard your app from spam and bots!

- URL: https://superails.com/posts/rails-7-2-rate-limiting-for-devise-guard-your-app-from-spam-and-bots
- Published: 2024-08-11
- Duration: 07:11
- Access: free
- Topics: security, devise

🔒 Secure your app from password-guessing attacks, spam, and abuse by rate-limiting your sign-up and sign-in pages.

I always rely on the wonderful rack-attack gem for this, capping requests per IP within a set timeframe.

Now Rails 7.2 adds native rate limiting out of the box!

Let's add rate limiting to your Devise Sign Up and Sign In pages & secure your app! 🛡️

Episode source code: https://github.com/corsego/183-rails-native-rate-limiting/commit/54b962dfa0a7e6407f99e4b3251e61edd5df964e
Based on this blogpost: https://blog.corsego.com/rails-rate-limiting

## Transcript

Hello friends, here's an old application that I built and here is the list of users. And as you can judge by these email addresses, they all look fake. This could be real people trying to sign into the application with fake data and try to have a look around All this could be actual bots that was spam in the registration page, trying to just create a lot of, uh, necessary data in the application. Usually when you have email and password log in into your application, you would want to guard from bots, uh, who are trying to spam your application with creating lots of fake users and especially should guard the log in page from bots that are making thousands of requests, trying to guess an email and possible combination and trying to log into somebody's account. Historically, I always use the gem rec attack to guard from, uh, bots trying to spam the login and uh, sign up page in the application. But as Rail 7.2 rails has its own native rate limiting feature, so you can add rate limiting without having, uh, any dependencies like rag attack. And, uh, re 7.2 has been released just a couple of days ago. So you can use this rate limiting out of the box and you see it is added on a controller action level. So here in the sessions, basically in the login page, it says that you can have maximum, maximum 10, uh, login, uh, requests within three minutes from the same AP address. If you have more, then you're going to get, uh, an error and you will not be able to, uh, submit the request, uh, for the first time. Actually saw this been used in the, the rails native authentication generator. Here is the code, then you generate that sessions controller. It adds rate limiting line by default. So let's try to add this kind of, uh, native rails seven uh, rate limiting into an application that uses device. And here is a basic application that has a home page, a dashboard that require authentication, log in and uh, sign up pages. And we're going to try to add the rate limiting to login and register so that there cannot be too many requests within a period of time from the same ip. Otherwise there should be an error. So, uh, looking at the example here, it is added on a controller level and uh, we don't actually have, uh, device controllers by default when we create a device, uh, uh, generated in the application. So we'll need to add the device controllers for sessions and registrations. So I'm gonna say rails generate device, uh, um, controllers, users, so for users and the controllers are, uh, registrations and sessions. Okay? So it created the, uh, two controllers and uh, I will go to my roots and uh, I will say device for users, controllers, sessions and registrations. Okay, so opening this controllers, I'm going to add this rate limit to let's say 10 within three minutes only on create to the sessions. So to the login page, let's add rate limiting and let's start the server. And you see going to the login page, you get this no method error and define method rate limit five. It. So because going to the jump file, I'm actually not trying rail 7.2, I'm run rail 7.1. So I will say rail 7.2 0.0 and run bundle. Okay, I will start the rail seven once again and I will say for the sake of example, I will limit it to two requests within, uh, three minutes. So let me open the console also, log in, log in, log in, and you see, uh, I don't seem to be getting any errors by, so because uh, it you it should be using the rails cache, but the rails cache is disabled by default in development. So we need to run the command rails, dev cache to enable caching in the development environment. Um, let me run it again. So it is no longer been cached. Now it is been cached. Okay, let's run the rails server. Now I will click login, login, log in again. And you see now I get this error two many requests. So if I refresh the page, I click log in and you see there is no request submitted, no errors have been rendered. And in the console I see this completed with two many requests. So I'm not actually submitting the form. So it's really nice. Uh, the form isn't been submitted because we are defending it with, uh, the straight limiting, but uh, we want to maybe give the user some input about, uh, what is happening. So we would want to like redirect the user and say that, uh, try again later as it happens in this example, uh, in the rail sessions controller generator. So let's go to this line and we will say limit 10 within three minutes. Only create and redirect the tool in device. We don't have this, uh, new session, URL, we have the new user session, session path. Okay, let's uh, try once again, I will click on login a few times and you see now I get a try again later flash message so it works quite file. And we can add the same way in our registrations controller. So here I will add the rate limit to 10 within three minutes as uh, it is done in the rail sessions. Gen generator. Maybe it is like a good, uh, combination of, uh, uh, attempts per interval of time. So let's add it to our registrations. And uh, I'm going to click send up multiple times. And you see I get this try again later, but again, I was redirected to the login page. So in the registrations control, I want to be redirected back to the register page. So here I will say in new user registrations path. And that is more or less it having a look at the docs of the straight limiting. You can uh, set different stores, you can store it in Redis, you can store it in the rail cache, and by default it responds with head too many requests and it responds based on the remote IP address. So on the IP address of the person who is trying to make the request, uh, we don't have to specify the code, uh, here. So in this scenario, like this is, uh, what would happen by default, but we don't need to specify it. So yeah, that's basically it. This is how you can add the rails native rate limiting to device, to the sign in page and to the sign up pages. Thanks for watching and see you in the next one.