Data Exposure in Chi with Mutual Tls

When a Chi service is configured to require mutual Transport Layer Security (mTLS), the presence of a client certificate is often treated as sufficient authentication. In practice, this can create a false sense of security and lead to data exposure when authorization checks are incomplete or misaligned with the identity encoded in the certificate.

During a black-box scan, middleBrick tests the unauthenticated attack surface. If the server accepts a valid client certificate but does not enforce principle-based authorization, an attacker who possesses any valid certificate can access data belonging to other principals. For example, a certificate issued to user_a might be used to request /patients/123, and if the server only verifies the certificate is trusted (and not that the subject is allowed to view patient 123), sensitive data is exposed. This becomes especially risky in environments where certificates are long-lived or where role or group claims are not validated on each request.

Another exposure vector involves metadata and reflection. Some Chi frameworks automatically serialize responses based on type names or include debug information when mTLS is enabled. middleBrick checks for data exposure by requesting the same endpoint with different valid identities and comparing responses. If one identity can infer the existence or structure of data accessible to another identity, or if error messages reveal stack traces or internal paths, the API fails this check.

Real-world findings from scans have mapped such issues to the OWASP API Top 10 2023 category Broken Object Level Authorization (BOLA) and to compliance areas such as PCI-DSS and HIPAA, where unauthorized viewing of data is a high-severity finding. Because mTLS is often perceived as strong security, teams may overlook granular authorization, resulting in an API that encrypts traffic but still leaks data.

middleBrick’s LLM/AI Security checks are relevant here as well. If an LLM endpoint in Chi is unauthenticated or permissive, and mTLS is used only for service-to-service calls, the scanner probes for prompt injection and output leakage. Output scanning looks for API keys or PII in responses, which may be inadvertently exposed when identity context is not properly validated on the server.

To summarize, Data Exposure in Chi with Mutual Tls occurs when transport security is assumed to replace authorization, when identity claims are not strictly enforced, and when response handling lacks safeguards. Detection involves comparing access across valid certificates and inspecting whether sensitive information is returned to subjects that should not see it.

Remediation focuses on ensuring that every request with a valid client certificate is explicitly authorized according to the subject’s identity, role, or group. Do not rely on the mere presence of a certificate to grant access to sensitive data.

Chi code examples for strict identity-based authorization

In Chi, you can inspect the certificate presented during the TLS handshake and enforce fine-grained controls before reaching your resource handlers.

open System.Security.Cryptography.X509Certificates
open Giraffe

let requireScope (requiredScope: string) (next: HttpFunc -> HttpContext -> HttpFuncResult) (ctx: HttpContext) =
    let user = ctx.User
    if user.Identity.IsAuthenticated then
        let scopes =
            user.FindFirst("scp")
            ?.Value
            ?.Split([|' '|], System.StringSplitOptions.RemoveEmptyEntries)
            |> Set.ofArray
        if scopes.Contains requiredScope then next ctx else setStatusCode 403 >= text "Insufficient scope" ctx
    else
        setStatusCode 401 >= text "Unauthenticated" ctx

let authorizePatientAccess (ctx: HttpContext) =
    let cert = ctx.Connection.ClientCertificate
    if cert = null then setStatusCode 400 >= text "Client certificate required" ctx else
    let subjectName = cert.Subject
    // Extract user ID from subject or claims; this is application-specific
    let userId = extractUserIdFromSubject subjectName
    let requestedId = ctx.GetRouteValue("patientId") :?> string
    if userId = requestedId then next() else setStatusCode 403 >= text "Forbidden" ctx

let app = router {
    get "/patients/:patientId" (requireScope "patient:read" (fun ctx -> task {
        let! patient = getPatientFromService ctx
        return! json patient ctx
    }))
    get "/patients/:patientId/details" (authorizePatientAccess (fun ctx -> task {
        let! details = getPatientDetails ctx
        return! json details ctx
    }))
}

The first handler uses a scope-based claim (scp) to allow or deny access. The second handler demonstrates identity-based matching by comparing the certificate subject-derived user ID to the route parameter patientId. This ensures that even with a valid mTLS certificate, a user cannot access another patient’s record.

Additionally, configure your Chi pipeline to reject requests that lack a client certificate when mTLS is required:

open Microsoft.AspNetCore.Server.Kestrel.Core

let configureKestrel (options: KestrelServerOptions) =
    options.ConfigureHttpsDefaults(fun opts ->
        opts.ClientCertificateMode <- ClientCertificateMode.RequireCertificate
        opts.AllowAnyClientCertificate() // Replace with custom validation in production
    )

In production, replace AllowAnyClientCertificate with a custom validator that checks revocation, enforces specific issuers, and maps certificates to application identities. Combine this with explicit authorization checks in each handler or via middleware to avoid conflating transport security with data access permissions.

middleBrick’s dashboard can track your security scores over time, and the Pro plan supports continuous monitoring so that new exposures are flagged as soon as they appear. The GitHub Action can enforce a minimum score in CI/CD, preventing merges if data exposure risks are detected after changes to mTLS configuration.