Api Rate Abuse in Grape with Mutual Tls

Rate abuse in a Grape API with mutual TLS (mTLS) involves a client that presents a valid certificate but still exceeds intended request volumes. mTLS ensures the client is who it claims to be by verifying its certificate, but it does not inherently enforce request limits. When mTLS is enabled without complementary rate controls, an authenticated client can make repeated abusive calls that consume resources, degrade performance, or incur costs. This combination exposes the API to authenticated-rate attacks: the attacker uses a legitimate certificate to bypass IP-based or unauthenticated checks, making abuse harder to detect.

Grape itself does not provide built-in rate limiting; it relies on middleware or external controls. If rate limiting is implemented at a layer that does not account for mTLS-authenticated identities, attackers can rotate among valid certificates or reuse a stolen certificate to avoid throttling. For example, a poorly configured limit that applies globally per IP may be bypassed by an attacker who controls multiple certificates from the same network. Conversely, limits tied only to certificate subject without considering downstream routing or load-balancer hops can be misaligned with actual service capacity, enabling bursts that overwhelm backend systems.

In practice, mTLS reduces the attack surface by ensuring only permitted clients can connect, but it narrows the scope of what can be used for rate attribution. You must attribute rate limits to a stable identifier extracted from the client certificate (such as a serial number, subject DN, or a custom extension) rather than to ephemeral network properties. Without this, the API may either block legitimate clients sharing infrastructure or permit abuse under valid credentials. The 5–15 second scan window of middleBrick can surface missing rate controls in mTLS-enabled endpoints by testing authenticated paths and checking whether rate-related findings appear in categories like Rate Limiting and Authentication.

Apply rate limits based on a stable value extracted from the client certificate, and enforce limits before business logic executes. Use middleware to read the verified certificate and map it to an identifier for throttling. Below are concrete, realistic snippets for a Grape API with mTLS enabled via Puma and an off-the-shelf rate-limiting strategy.

1) Verify client certificates with mTLS in Puma

Configure your Ruby/Puma setup to require client certificates. This example uses a minimal Puma setup with SSL verification; adjust paths to your CA and certificate store as needed.

# config/puma.rb
ssl_bind '0.0.0.0', '8443', {
  key: '/etc/ssl/private/server.key',
  cert: '/etc/ssl/certs/server.crt',
  ca_file: '/etc/ssl/certs/ca_bundle.crt',
  verify_mode: 'verify_peer'
}

2) Extract certificate identity in Grape middleware

Add a request before filter that extracts a stable identifier (e.g., serial number) from the client cert and stores it on the environment for downstream use.

# lib/middleware/client_cert_identifier.rb
class ClientCertIdentifier
  def initialize(app)
    @app = app
  end

  def call(env)
    if env['SSL_CLIENT_CERT']
      cert = OpenSSL::X509::Certificate.new(env['SSL_CLIENT_CERT'])
      # Use serial as a stable identifier; you can also parse subject DN or SAN extensions
      env['HTTP_X_CLIENT_SERIAL'] = cert.serial.to_s
    else
      env['HTTP_X_CLIENT_SERIAL'] = 'unknown'
    end
    @app.call(env)
  end
end

Insert the middleware before Grape in your Rack stack (e.g., in config.ru):

# config.ru
require_relative 'lib/middleware/client_cert_identifier'
use ClientCertIdentifier
run MyApi

3) Apply rate limits per certificate identity

Use a token-bucket or fixed-window strategy keyed by the extracted serial. The example below uses a thread-safe in-memory store for illustration; in production, use Redis or another shared store when running multiple workers.

# lib/rate_limit_by_cert.rb
require 'thread'

class RateLimitByCert
  LIMIT = 300  # requests
  WINDOW = 60  # seconds

  def initialize
    @store = {}           # serial => { count: Integer, reset_at: Time }
    @mutex = Mutex.new
  end

  def allowed?(serial)
    now = Time.now
    state = @mutex.synchronize(@store[serial] ||= { count: 0, reset_at: now + WINDOW })

    if now >= state[:reset_at]
      state[:count] = 1
      state[:reset_at] = now + WINDOW
      true
    elsif state[:count] < LIMIT
      state[:count] += 1
      true
    else
      false
    end
  end
end

RATELIMITER = RateLimitByCert.new

Integrate the check into your Grape API or a base class:

# api/base.rb
class BaseAPI < Grape::API
  before do
    serial = env['HTTP_X_CLIENT_SERIAL']
    unless RATELIMITER.allowed?(serial)
      error!({ error: 'rate_limit_exceeded' }, 429)
    end
  end
end

4) Combine with standard Rack::Attack for broader controls

You can layer Rack::Attack using the certificate serial as a throttle key while preserving mTLS verification.

# config/initializers/rack_attack.rb
Rack::Attack.throttle('requests by cert serial', limit: 300, period: 60) do |req|
  req.env['HTTP_X_CLIENT_SERIAL'] || req.ip
end

Rack::Attack.throttled_response = ->(env) {
  [429, {}, ['{"error":"rate_limit_exceeded"}']]
}

With these steps, mTLS identifies clients reliably and rate limits are applied per authenticated identity, preventing certificate-based abuse while minimizing impact on legitimate users.