Brute Force Attack in Rails with Mutual Tls

A brute force attack against a Rails application using mutual TLS (mTLS) can be particularly nuanced because the presence of client certificates shifts some authentication burden to the TLS layer. With mTLS, the server requests a client certificate during the TLS handshake and validates it before the Rails router or application code is reached. If certificate validation is misconfigured or if the attacker can obtain or guess a valid client certificate, the attacker can then focus on application-level credentials. Rails’ default setup often authenticates users via session cookies or tokens after the TLS layer has already established the client identity, which may lead to a false sense of security.

When mTLS is used but the application still relies on weak account passwords or lacks rate limiting on login endpoints, an attacker who possesses a valid client certificate can systematically attempt passwords or session tokens. Because the TLS layer has already authenticated the client, the Rails app may treat subsequent requests as authenticated, allowing unchecked brute force attempts against account passwords or API tokens. Additionally, if the Rails app uses HTTP basic authentication over mTLS, the combination can expose credentials to offline brute force if the traffic is captured and the password is weak, despite the presence of TLS.

Another angle is certificate mapping to application identities. If the Rails app maps the client certificate’s subject or serial to a user or role without additional checks, an attacker who compromises a low-privilege certificate can attempt to escalate by brute forcing session tokens or leveraging insecure direct object references (BOLA/IDOR) within the Rails app. The perceived security of mTLS can therefore mask a weak application authentication layer, making brute force against credentials or tokens a viable path once the TLS identity is established.

Consider a Rails controller that relies on a client certificate for initial identification but then uses predictable resource identifiers:

class Api::V1::ReportsController < ApplicationController
  before_action :verify_client_cert

  def show
    user = User.find_by(certificate_serial: request.client_cert.serial)
    report = Report.find(params[:id])
    render json: report if report.user_id == user.id
  end

  private

  def verify_client_cert
    head :forbidden unless request.client_cert.present?
  end
end

In this example, the route /api/v1/reports/:id is protected by mTLS, but the controller performs a BOLA/IDOR check by comparing report.user_id to the certificate-mapped user. An attacker with a valid certificate can brute force numeric IDs to access other users’ reports, illustrating how brute force can pivot on mTLS-enabled endpoints when authorization is not sufficiently enforced.

To harden Rails applications using mTLS, enforce strict certificate validation, avoid implicit trust, and apply defense-in-depth controls such as rate limiting and monitoring. Treat the mTLS identity as an assertion of transport-layer identity, not as a replacement for application-level authorization and brute force protections.

1. Enforce certificate validation and map identities safely

Ensure the Rails app validates the client certificate chain and does not trust headers or forwarded values for authentication. Map the certificate to a user with a secure lookup and apply additional authorization checks.

# config/initializers/ssl_client_cert.rb
module SslClientCert
  def self.user_from_request(request)
    cert = request.client_cert
    return nil unless cert
    # Verify certificate fingerprints or extensions if needed
    fingerprint = cert.fingerprint
    User.find_by(certificate_fingerprint: fingerprint)
  end
end

Use this in controllers and ensure strong authorization on each sensitive action:

class Api::V1::ReportsController < ApplicationController
  before_action :authenticate_with_mtls!
  before_action :authorize_report_access, only: [:show]

  def show
    report = Report.find(params[:id])
    render json: report
  end

  private

  def authenticate_with_mtls!
    @current_user = SslClientCert.user_from_request(request)
    head :unauthorized unless @current_user
  end

  def authorize_report_access
    report = Report.find(params[:id])
    head :forbidden unless report.user_id == @current_user&.id
  end
end

2. Apply rate limiting to authenticated endpoints

Even with mTLS, limit requests to sensitive endpoints to mitigate brute force attempts. Use Rails cache-based rate limiting to throttle by certificate identity or IP.

# app/controllers/concerns/rate_limited.rb
module RateLimited
  extend ActiveSupport::Concern

  RATE_LIMIT = 30 # requests
  RATE_PERIOD = 60 # seconds

  included do
    before_action :apply_rate_limit
  end

  def apply_rate_limit
    key = "rate_limit:#{current_identity_key}"
    count = Rails.cache.read(key) || 0
    if count >= RATE_LIMIT
      head :too_many_requests
    else
      Rails.cache.write(key, count + 1, expires_in: RATE_PERIOD.seconds)
    end
  end

  def current_identity_key
    # Use certificate fingerprint or a stable user identifier
    request.client_cert ? request.client_cert.fingerprint : request.ip
  end
end

Include this concern in controllers where mTLS is used and consider tighter limits for high-risk actions such as password changes or token issuance.

3. Implement account and token protections

Enforce strong password policies, account lockout or delays after repeated failures, and rotate API tokens. Use Rails built-in mechanisms and avoid relying on mTLS alone for authorization decisions.

# app/models/user.rb
class User < ApplicationRecord
  has_secure_password validations: false
  validates :password, length: { minimum: 12 }, if: :password_required?

  def self.with_mtls_identity(cert)
    return none unless cert
    find_by(certificate_fingerprint: cert.fingerprint)
  end

  private

  def password_required?
    !password.nil? || !password_confirmation.nil?
  end
end

4. Monitor and log mTLS identity usage

Log certificate fingerprints and request paths to detect unusual patterns that may indicate brute force or probing behavior. Avoid logging full certificates or sensitive material.

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  around_action :log_mtls_identity

  def log_mtls_identity
    Rails.logger.info "[mTLS] fingerprint=#{request.client_cert.fingerprint} path=#{request.path}"
    yield
  end
end

Combine these measures with regular review of access patterns and periodic certificate rotation to reduce the risk of brute force attacks in mTLS-enabled Rails applications.