Camping is a minimalist Ruby micro-framework that lacks built-in protection against volumetric attacks. Without explicit rate limiting, an attacker can saturate your application's worker pool or database connections by flooding resource-intensive endpoints. In a production environment, we mitigate this by injecting Rack middleware to enforce request quotas at the entry point.

The Vulnerable Pattern

require 'camping'
Camping.goes :VulnerableCamp
module VulnerableCamp::Controllers
class Login < R ‘/login’
def post
# Vulnerable: No limit on attempts.
# Attacker can brute-force or exhaust resources here.
user = User.authenticate(input.username, input.password)
user ? “Welcome” : “Fail”
end
end
end

The Secure Implementation

The vulnerability exists because Camping handles every incoming request until the underlying web server (like Puma or Thin) reaches its thread limit. By integrating 'Rack::Attack', we intercept the request at the Rack layer before it reaches the Camping controller. We define a throttle rule based on the client's IP address and the specific route. If the threshold is exceeded, the middleware short-circuits the request with an HTTP 429 'Too Many Requests' response, protecting the application's CPU and database from exhaustion.

require 'camping'
require 'rack/attack'
Camping.goes :SecureCamp
Configure Rack::Attack middleware
SecureCamp.use Rack::Attack
Throttle login attempts by IP to 5 requests every 30 seconds
Rack::Attack.throttle(‘logins/ip’, limit: 5, period: 30) do |req|
req.ip if req.path == ‘/login’ && req.post?
end
Return a 429 status code when throttled
Rack::Attack.throttled_response = lambda do |env|
[429, { ‘Content-Type’ => ‘application/json’ }, [{ error: ‘Rate limit exceeded. Try again later.’ }.to_json]]
end
module SecureCamp::Controllers
class Login < R ‘/login’
def post
“Authentication logic executed.”
end
end
end