Protect your sign up form with Rack::Attack

When your application becomes popular it may attract the attention of hackers, who’ll try and find ways to exploit the weaknesses in your site to use it for nefarious means!

I'm co-chairing RailsConf 2024 in Detroit May 7–9.
Come and join us →

They’ll nearly always explore your site manually, signing up and testing attack vectors, before attempting to automate the weaknesses they’ve discovered.

During an attack, the hacker’s bots will typically sign up with a random email then do something bad, hundreds of times a minute, from a relatively small number of computers.

Instead of…

…allowing unlimited sign up attempts…

Use…

…Rack::Attack to limit the frequency of sign ups and ban the offending IP addresses.

Gemfile

gem 'rack-attack'

config/application.rb

module YourAppName
  class Application < Rails::Application
    config.middleware.use Rack::Attack
  end
end

config/initializers/rack_attack.rb

class Rack::Attack
  Rack::Attack.throttle("users/sign_up", limit: 3, period: 15.minutes) do |req|
     # Using “vanilla” devise inside a User model
    req.ip if req.path == "/users" && req.post?
  end
end if Rails.env.production?

But why?

The judicious use of endpoint-based request restriction can prevent your site from being an attractive target for spammers and hackers. It can also reduce the size of any successful bot attack by limiting the amount of possible signups.

In this example, hackers can only add up to three users every quarter of an hour. If you think 15 minutes seems too brief you could probably increase the period duration to twenty or thirty minutes without accidentally blocking any legitimate sign ups.

Why not?

The solution above could, in theory, block legitimate sign ups, but it is highly unlikely that a user would incorrectly attempt to sign up three times in relatively quick succession.

Still running UK’s friendliest, Ruby event on Friday 28th June.
Ice cream + Ruby →