Missing Authentication in Chi with Mutual Tls

In Chi, mutual Transport Layer Security (mTLS) requires both the client and the server to present valid certificates during the TLS handshake. When authentication is missing or misconfigured in a Chi-based service, the server may accept incoming requests even when a client certificate is not provided or is invalid. This creates a gap where the endpoint effectively becomes unauthenticated despite mTLS being advertised as a security control.

Chi is a minimalistic router for Go that relies on standard http.Request and http.Server configurations. If the server’s TLS settings do not enforce client certificate verification, an attacker can send requests that reach route handlers without proving their identity. This is a classic case of missing authentication in the application layer, even when transport-layer mTLS is in place.

During a black-box scan, middleBrick tests the unauthenticated attack surface of Chi endpoints. It checks whether route handlers execute without validating client identity. If a handler returns sensitive data or performs privileged actions without confirming the client’s certificate, the finding is categorized under Authentication, and the risk score reflects the severity of unauthorized access.

Real-world attack patterns such as insecure default configurations or omitted verification logic often lead to these gaps. For example, developers may configure tls.Config with ClientAuth set to tls.NoClientCert instead of tls.RequireAndVerifyClientCert, which disables mandatory client certificate validation. This misconfiguration allows any client to reach authenticated routes, bypassing intended access controls.

middleBrick’s LLM/AI Security checks do not apply here, but the scanner’s Authentication and BOLA/IDOR checks are relevant. These tests validate whether endpoints enforce identity checks and whether one entity can access another’s resources through predictable identifiers. The tool also cross-references findings with the OpenAPI specification, if provided, to detect inconsistencies between declared security requirements and runtime behavior.

Compliance frameworks such as OWASP API Top 10 (2023) A07:2023 — Identification and Authentication Failures highlight the importance of proper authentication. Missing authentication in Chi routes violates this control, regardless of the presence of mTLS, because the application does not verify who is making the request.

To fix missing authentication in Chi services using mTLS, enforce client certificate verification at the http.Server level. This ensures that every connection presents a valid certificate before requests reach Chi handlers.

Example: Correct mTLS configuration in Chi

The following example demonstrates a secure setup using Go’s crypto/tls package. It loads server and client CA certificates and requires verified client certificates for every connection.

import (
    "crypto/tls"
    "crypto/x509"
    "io/ioutil"
    "net/http"

    "github.com/go-chi/chi/v5"
)

func main() {
    // Load server certificate and key
    cert, err := tls.LoadX509KeyPair("server.crt", "server.key")
    if err != nil {
        panic(err)
    }

    // Load client CA pool to verify clients
    caCert, err := ioutil.ReadFile("ca.crt")
    if err != nil {
        panic(err)
    }
    caCertPool := x509.NewCertPool()
    caCertPool.AppendCertsFromPEM(caCert)

    // Configure TLS with mandatory client verification
    tlsConfig := &tls.Config{
        Certificates: []tls.Certificate{cert},
        ClientCAs:    caCertPool,
        ClientAuth:   tls.RequireAndVerifyClientCert,
        MinVersion:   tls.VersionTLS12,
    }

    server := &http.Server{
        Addr:      ":8443",
        TLSConfig: tlsConfig,
    }

    r := chi.NewRouter()
    r.Get("/secure", func(w http.ResponseWriter, r *http.Request) {
        // At this point, the client certificate has been verified
        w.Write([]byte("Authenticated response"))
    })

    server.Handler = r
    server.ListenAndServeTLS("", "")
}

Key points in this configuration:

• ClientAuth: tls.RequireAndVerifyClientCert ensures that clients must present a certificate signed by the trusted CA.
• ClientCAs defines the set of acceptable client certificates.
• Using MinVersion: tls.VersionTLS12 enforces modern protocol standards.

If you are using middleware within Chi for logging or recovery, authentication checks should still be enforced at the server level. This prevents handlers from being invoked without verified client identity.

When testing with middleBrick, rescan the endpoint after applying this configuration. The scanner will verify whether client certificate validation is enforced and whether unauthenticated requests are rejected.

For teams using the middleBrick CLI, running middlebrick scan <url> after deployment helps confirm that the configuration is correctly enforced in the runtime environment. The Pro plan’s continuous monitoring can alert you if a future change weakens authentication requirements.