Pii Leakage in Grape with Mutual Tls

Grape is a REST-like API micro-framework for Ruby that sits on top of Rack. When mutual TLS (mTLS) is used, the server requests and validates a client certificate during the TLS handshake. If the application layer in Grape does not independently validate authorization for specific resources, mTLS alone does not prevent Insecure Direct Object References (IDOR) or improper authorization leading to PII leakage.

Consider an endpoint that exposes user profiles:

class V1 < Grape::API
  format :json

  before { authenticate!

With mTLS, authenticate! might simply confirm the certificate was trusted, but it may not verify that the certificate’s subject (e.g., a user ID or UUID mapped from the certificate) matches the requested resource. An attacker who possesses a valid client certificate can iterate over user IDs (e.g., /v1/profile/123, /v1/profile/124) and read PII belonging to other users because the server trusts the certificate and returns data without checking ownership or role-based permissions.

This is a BOLA/IDOR pattern: the trust boundary is at the transport layer (mTLS), but the application fails to enforce authorization at the resource level. Input validation checks may also be insufficient; if parameters are not strictly whitelisted, an attacker might inject paths or modify query strings to leak additional PII, such as email addresses or phone numbers stored in the response. Even with mTLS, if the API does not enforce rate limiting, an attacker can perform credential or resource enumeration attacks to accelerate discovery of valid PII-bearing records.

Moreover, if the server inadvertently includes sensitive data in error messages or headers (for example, stack traces revealing file paths or internal identifiers), data exposure risks increase. Encryption in transit is provided by TLS, but encryption does not equate to access control. Without proper property authorization checks, PII can be leaked through seemingly authenticated and encrypted channels when mTLS is used in Grape without tying certificate identities to fine-grained authorization logic.

Remediation requires coupling mTLS with explicit authorization and input validation inside Grape. Treat the client certificate as an identity claim, not as an authorization token. Map the certificate’s subject or a SAN (Subject Alternative Name) to a user or API key, then enforce ownership or role checks on every request.

Example mapping from certificate to user (using the ssl_client_cert Rack environment variable provided by your server, such as Puma or Passenger behind a load balancer that terminates TLS):

class V1 < Grape::API
  format :json

  before do
    # Map certificate to user
    cert = request.env['SSL_CLIENT_CERT']
    raise Grape::Exceptions::Unauthorized, 'Client certificate required' unless cert

    # Extract a serial or subject field and look up the user
    subject = cert.subject.to_s
    user_id = extract_user_id_from_subject(subject) # implement this mapping
    @current_user = User.find_by(mtls_subject: subject)
    # or validate against a mapping table
    # @current_user = User.find_by(certificate_serial: cert.serial.to_s)

    # Enforce authorization for the requested resource
    requested_id = params['id']
    unless @current_user&.can_access_profile?(requested_id)
      raise Grape::Exceptions::Forbidden, 'You cannot access this resource'
    end
  end

  resource :profiles do
    desc 'Get a user profile, PII protected by mTLS + authorization'
    params do
      requires :id, type: String, desc: 'Profile identifier'
    end
    get ':id' do
      profile = Profile.find(params[:id])
      # Ensure the profile belongs to the authenticated principal
      error!('Not found', 404) unless profile.user == @current_user
      { name: profile.name, email: profile.email, phone: profile.phone }
    end
  end
end

Key practices:

• Never rely on mTLS alone for authorization. Always map certificate identity to a user/role and enforce checks at the resource or field level.
• Validate and sanitize all inputs, even when mTLS is used. Use strong parameter whitelisting to limit returned PII fields.
• Apply rate limiting to mitigate enumeration attacks that exploit valid certificates to probe for PII.
• If using an API gateway or load balancer, ensure it forwards certificate details securely to the backend (e.g., setting X-SSL-Client-Cert or equivalent) and that the connection between gateway and backend is trusted.

These steps ensure that PII leakage is mitigated by combining mTLS for transport-layer identity with application-layer authorization and input validation, aligning with checks such as Authentication, BOLA/IDOR, and Property Authorization included in middleBrick scans.