Api Rate Abuse in Rails with Jwt Tokens

Rate abuse occurs when an attacker makes excessive requests to an API endpoint, consuming resources, causing denial of service, or enabling brute-force and enumeration attacks. In a Ruby on Rails application using JWT for stateless authentication, the combination of per-request token validation and missing or weak rate controls creates a specific attack surface.

JWTs are typically validated on each request by decoding and verifying the signature and claims. Because the server does not keep server-side session state by default, there is no built-in mechanism to track how many requests a given token or subject has made within a time window. If rate limiting is implemented at a lower layer (e.g., by IP) only, a single attacker can rotate IPs or use a botnet, while the JWT identity remains unchallenged per request. This enables attackers to test stolen or guessed tokens, perform credential stuffing against protected endpoints, or flood specific user-scoped routes.

Another dimension is endpoint enumeration. Without rate limits on token validation or user info endpoints, attackers can iterate through user IDs or UUIDs and learn which tokens are valid based on response differences, even when the token itself is well-formed. JWTs often embed user identifiers in claims, and if those endpoints do not apply token-aware rate limits, attackers can map valid tokens to user accounts without triggering account lockouts that would exist in traditional password-based flows.

The stateless nature of JWTs also complicates revocation during attack windows. Traditional session invalidation is straightforward, but with JWTs, short-lived tokens continue to be accepted until expiry. If an attacker obtains a token, the window for abuse remains open for the token’s lifetime unless additional mechanisms, such as short expirations, token denylists, or per-token usage counters, are introduced. Without these, endpoints that rely solely on JWT for authentication but lack request-rate constraints are vulnerable to high-volume abuse.

In Rails, common misconfigurations include applying rate limits only in the web server or CDN, placing them before JWT authentication, or using coarse-grained limits that do not consider the authenticated identity. For example, a limit of 100 requests per IP per minute may be insufficient when tokens are long-lived and IPs are easy to change. The correct approach is to enforce rate limits after successful JWT authentication and scope them to the token’s subject or a client-assigned API key, ensuring that each authenticated principal is protected independently of network-level identifiers.

To mitigate rate abuse with JWT in Rails, apply token-aware rate limits after authentication, use short token lifetimes, and incorporate per-token usage tracking. Below are concrete, realistic code examples to implement these controls.

1. Token-aware rate limiting with Redis. After verifying the JWT, use the subject (sub) or a stable user identifier to scope requests. This example uses the redis-rails gem and a Rack middleware approach to count requests per user within a sliding window.

class JwtRateLimiter
  RATE_LIMIT = 300 # requests
  WINDOW = 60    # seconds

  def initialize(app)
    @app = app
  end

  def call(env)
    req = Rack::Request.new(env)
    token = extract_token(req)
    if token && (payload = decode_token(token))
      user_id = payload['sub'] || payload['user_id']
      key = "rate_limit:jwt:#{user_id}"
      current = $redis.incr(key)
      $redis.expire(key, WINDOW) if current == 1
      if current > RATE_LIMIT
        return [429, { 'Content-Type' => 'application/json' }, [{ error: 'rate_limit_exceeded' }.to_json]]
      end
    end
    @app.call(env)
  rescue JWT::DecodeError, JWT::ExpiredSignature
    # proceed without rate limiting by user, but consider logging
    @app.call(env)
  end

  private

  def extract_token(req)
    auth = req.env['HTTP_AUTHORIZATION']
    auth&.split(' ')&.last
  end

  def decode_token(token)
    # Use your Rails secret and algorithm consistent with your app
    JWT.decode(token, Rails.application.secrets.secret_key_base, true, { algorithm: 'HS256' }).first
  end
end

# config/application.rb or an initializer
Rails.application.config.middleware.use JwtRateLimiter

2. Short-lived access tokens with refresh rotation. Set a short exp (e.g., 15 minutes) and use a refresh token stored server-side with its own rate and revocation controls. When an access token is near expiry, the client uses a refresh token to obtain a new access token. This limits the usefulness of a stolen token and reduces the window for token brute-force.

class TokenDenylist
  def self.add(jti, exp)
    # $redis is a connected Redis instance
    ttl = [exp.to_i - Time.now.to_i, 0].max
    $redis.setex("denylist:#{jti}", ttl, 'true')
  end

  def self.include?(jti)
    $redis.get("denylist:#{jti}").present?
  end
end

# In your JWT verification flow
def decode_token(token)
  payload = JWT.decode(token, Rails.application.secrets.secret_key_base, true, { algorithm: 'HS256' }).first
  raise 'Token revoked' if TokenDenylist.include?(payload['jti'])
  payload
end

begin
  decoded = JWT.decode(token, Rails.application.secrets.secret_key_base, true, { algorithm: 'HS256' })
rescue JWT::VerificationError, JWT::DecodeError => e
  Rails.logger.warn("JWT verification failed: #{e.message}")
  raise ActionController::UnauthorizedError
end