Insecure Design in Axum with Mutual Tls

Insecure design in an Axum service that enables Mutual TLS (mTLS) often centers on how the application validates and uses client certificates. When mTLS is configured without strict certificate validation, or when the application treats the presence of a TLS certificate as sufficient authorization, it introduces a design gap between transport-layer assurance and application-level trust. Axum, being a Rust web framework, does not enforce certificate validation semantics by itself; that behavior depends on the underlying hyper and native-tls (or rustls) configuration and on the developer’s implementation choices.

A common insecure pattern is accepting any client certificate issued by a trusted CA without verifying the certificate’s intended purpose, extended key usage, or revocation status. If the application uses the certificate’s subject or common name to derive identity or authorization decisions, an attacker who obtains any valid client certificate can impersonate that principal across the API. This design conflates transport identity with application authorization, which is a violation of the principle of least privilege and enables Insecure Design–style weaknesses such as Insecure Direct Object References or Privilege Escalation.

Another design flaw is failing to enforce mTLS on all endpoints consistently. An Axum router might apply TLS configuration to only a subset of routes, leaving administrative or sensitive endpoints unprotected. If the service also exposes unauthenticated endpoints for health checks or metadata, an attacker can probe these paths to infer the presence of mTLS and then pivot to misconfigured routes. Additionally, storing or logging client certificate information without appropriate safeguards can lead to unintended data exposure, especially if logs are shared across teams or systems.

These issues are detectable by middleBrick’s 12 security checks, which include Authentication, BOLA/IDOR, Authorization, Input Validation, and LLM/AI Security. For example, if client certificates are accepted but not validated for revocation or purpose, middleBrick can flag this as a high-severity design weakness tied to authentication bypass risk. The scanner also cross-references OpenAPI specifications with runtime behavior, so discrepancies between documented authentication requirements and actual enforcement are surfaced as actionable findings with severity, impact, and remediation guidance.

To remediate insecure design issues when using mTLS in Axum, enforce strict certificate validation and align transport security with application-level authorization. Use rustls to configure a server that requires and verifies client certificates, and ensure that each request’s identity is mapped to an application identity with explicit authorization checks.

The following example shows a secure Axum server configured with rustls, requiring client authentication and validating the certificate chain:

use axum::{routing::get, Router};use std::net::SocketAddr;use tokio_rustls::rustls::{self, server::AllowAnyAuthenticatedClient};use tokio_rustls::TlsAcceptor;
let certs = rustls_pemfile::certs(&mut std::io::BufReader::new(std::fs::File::open("ca.crt")?))?;let mut roots = rustls::RootCertStore::empty();for cert in certs {roots.add(&rustls::Certificate(cert))?;}let client_auth = AllowAnyAuthenticatedClient::new(roots);let tls_config = rustls::ServerConfig::builder()    .with_safe_defaults()    .with_client_auth_cert(vec![client_auth])?    .with_single_cert(        vec![rustls::Certificate(std::fs::read("server.crt")?)],        rustls::PrivateKey(std::fs::read("server.key")?),    )?;let tls_acceptor = TlsAcceptor::from(Arc::new(tls_config));let addr = SocketAddr::from(([127, 0, 0, 1], 3000));let app = Router::new().route("/health", get(|| async { "ok" }))    .layer(/* your authorization layer */);axum::Server::bind(&addr)    .tls_config(tls_acceptor)?    .serve(app.into_make_service())    .await?;

This configuration ensures that the server rejects connections without a valid client certificate signed by the trusted CA. It avoids accepting any certificate by explicitly building a root store and using AllowAnyAuthenticatedClient to enforce chain validation. In production, you should also enable revocation checking via OCSP or CRL depending on your risk profile.

Additionally, do not rely on certificate fields (such as Common Name) for authorization. Instead, extract a stable user identifier from a custom extension or mapped assertion and perform explicit authorization in your route handlers. Combine this with rate limiting and continuous monitoring via middleBrick’s Pro plan to detect anomalies in authentication patterns or privilege misuse across your API surface.