Broken Access Control in Rails with Mutual Tls

Broken Access Control occurs when an API or web application fails to enforce proper authorization checks, allowing one user to access or modify data and functionality they should not be able to reach. In Ruby on Rails, developers commonly rely on application-level authentication and authorization (e.g., current_user checks, Pundit or CanCanCan policies) to gate endpoints. Mutual Transport Layer Security (Mutual TLS), where the client presents a certificate in addition to the server verifying its identity, is sometimes used to add connection-level assurance. However, Mutual TLS does not automatically enforce per-user or per-role authorization; it only authenticates the identity of the client at the transport layer. When developers assume Mutual TLS replaces application-level access controls, or when they map client certificates 1:1 to permissions without explicit checks, the combined setup can expose BOLA/IDOR and privilege escalation opportunities.

Consider a Rails API that uses Mutual TLS to authenticate clients. The server validates the client certificate and extracts a subject or serial number, then uses that value directly to scope data queries without additional authorization logic. For example, a route like GET /organizations/:id/users might verify the certificate and assign an org_id based on the certificate’s organizational unit (OU). If the endpoint then does something like Organization.find(org_id) without confirming that the authenticated subject is allowed to view that organization’s users, an attacker who possesses a valid client certificate for another organization can change the org_id parameter and enumerate or manipulate data across organizations — a classic BOLA/IDOR. OWASP API Top 10 A01:2023 broken access control and A07:2023 identification and authentication failures map closely here, because the trust boundary is misaligned: transport-layer identity is not equivalent to application-layer authorization.

In practice, this misalignment is exacerbated when authorization rules are complex (e.g., hierarchical roles, multi-tenant ownership, attribute-based conditions). Mutual TLS can provide a stable client identity (e.g., a certificate serial or subject), but if the Rails app does not re-check that identity against a policy that respects tenant boundaries, row-level security, or ownership fields, the system remains vulnerable. Attack patterns include tampering with numeric or UUID identifiers, exploiting missing index checks on associated models, or leveraging predictable references to access related records. Even with Mutual TLS in place, missing or inconsistent access checks at the controller or service layer leave the API open. This is why middleBrick scans include checks for BOLA/IDOR and Property Authorization, to verify that every authenticated request enforces granular, context-aware authorization rather than assuming transport-layer credentials suffice.

To securely combine Mutual TLS with robust access control in Rails, treat the client certificate as an authenticated identity source and then enforce explicit, policy-based authorization. Do not use certificate fields as a direct replacement for row-level permissions. Below are concrete patterns and code examples to implement this correctly.

1. Configure Rails to require and verify client certificates

In your web server (e.g., Nginx or Apache) and Rails setup, enforce client certificate verification. Within Rails, you can expose the verified certificate details via middleware or a before_action so controllers can access them safely without assuming authorization.

# config/application.rb or an initializer
module MyApp
  class Application < Rails::Application
    # Ensure the app reads the client certificate subject from the request header set by the proxy/server
    config.middleware.use "SslClientCertHeaderMiddleware"
  end
end

# lib/ssl_client_cert_header_middleware.rb
class SslClientCertHeaderMiddleware
  def initialize(app)
    @app = app
  end

  def call(env)
    # Assuming your reverse proxy sets SSL_CLIENT_CERT or you terminate TLS at the proxy and forward the cert fingerprint
    cert_fingerprint = env["HTTP_X_SSL_CLIENT_FINGERPRINT"]
    subject_dn = env["HTTP_X_SSL_CLIENT_SUBJECT"]
    # Store in request for later use in controllers or policies
    RequestContext.store(certificate_fingerprint: cert_fingerprint, subject_dn: subject_dn)
    @app.call(env)
  end
end

2. Map certificate identity to a user or org policy, not direct lookup

Do not perform Organization.find_by(certificate_serial: cert_sn). Instead, resolve the subject to a user or org membership, then enforce ownership or role checks via your existing policies (Pundit/CanCanCan). Here is an example using Pundit and a before_action to load a policy scope.

class Api::V1::UsersController < ApplicationController
  before_action :set_actor_from_cert
  before_action :authorize_user_index, only: [:index]

  def index
    @users = policy_scope(User).where(organization_id: @current_actor.organization_id)
    render json: @users
  end

  private

  def set_actor_from_cert
    # RequestContext is populated by the middleware with certificate details
    ctx = RequestContext.fetch
    subject = ctx[:subject_dn]
    # Example mapping: subject contains CN=username,OU=org,O=corp — parse or use a mapping service
    @current_actor = ActorMapping.from_subject(subject)
    # If no mapping found, reject request
    render plain: "Forbidden", status: :forbidden unless @current_actor
  end

  def authorize_user_index
    # Enforce tenant scoping via policy; do not trust params alone
    authorize User, :index?
  end
end

# app/policies/user_policy.rb
class UserPolicy < ApplicationPolicy
  def index?
    # Only allow users within the same organization as the authenticated actor
    record.organization_id == user.organization_id
  end

  def show?
    # BOLA protection: ensure user belongs to the same organization
    index?
  end
end

3. Use strong parameter scoping and avoid direct param-driven queries

Never rely on params[:org_id] or params[:id] to infer ownership. Always scope queries through the actor’s context and use Rails scopes or policy scopes. For example, instead of Organization.find(params[:id]), use a policy scope that filters by the actor’s organization and then authorize the specific instance.

class Api::V1::OrganizationsController < ApplicationController
  before_action :set_actor_from_cert

  def show
    @org = policy_scope(Organization).find(params[:id])
    authorize @org
    render json: @org
  end

  private

  def set_actor_from_cert
    ctx = RequestContext.fetch
    @current_actor = ActorMapping.from_subject(ctx[:subject_dn])
  end
end

4. Complementary server-side protections

Even with Mutual TLS, implement defense in depth: use Rails strong parameters, validate ownership on create/update/destroy actions, and employ application-level row-level security where applicable (e.g., PostgreSQL RLS via a gem or custom scopes). Combine these with the runtime checks that middleBrick performs to ensure your authorization logic aligns with the actual runtime behavior.