Broken Authentication in Actix with Mutual Tls

Mutual Transport Layer Security (mTLS) in Actix requires both the client and the server to present and validate digital certificates. When mTLS is configured incorrectly or when authentication logic is layered on top of mTLS without care, it can lead to Broken Authentication despite the presence of strong transport‑level guarantees. middleBrick’s checks for Authentication and BOLA/IDOR highlight these risks by correlating TLS setup with session and authorization behavior.

In practice, developers may assume that mTLS alone is sufficient to identify and authenticate users. However, mTLS only proves that a connecting peer possesses a valid certificate issued by a trusted Certificate Authority; it does not by itself map a certificate to a user or role inside the application. If the Actix service maps identities solely based on certificate fields (e.g., Common Name or Subject Alternative Name) and those mappings are handled inconsistently, an attacker who obtains a valid certificate can impersonate other users horizontally (BOLA) or escalate privileges (Privilege Escalation).

Another vulnerability pattern occurs when mTLS is enforced for some routes but not all, or when certificate verification is bypassed in development code that carries into production. For example, an Actix app might verify client certificates for the admin API but neglect to enforce the same depth of verification for user-facing endpoints, creating an authentication gap. Additionally, if the application uses the certificate for authentication but then relies on weak or missing session management (e.g., missing rotation of API tokens derived from cert claims), the effective authentication can be undermined.

middleBrick’s unauthenticated scanning reveals these gaps by probing endpoints without credentials and checking whether authentication enforcement is consistent across the surface. Findings can include missing verification on routes, overly permissive certificate validation logic, and missing checks on certificate revocation (CRL/OCSP), all of which contribute to a weak authentication posture in an mTLS-enabled Actix service.

Remediation centers on strict certificate validation, explicit identity mapping, and consistent enforcement across all routes. Below are concrete, realistic examples for an Actix web service using native Rust TLS support with rustls.

1. Enforce mTLS on all routes with strict client certificate verification

Configure your Actix server to require client certificates and validate them against a trusted CA. Do not skip verification in any environment.

use actix_web::{web, App, HttpServer, Responder};
use actix_web::dev::Server;
use std::sync::Arc;
use rustls::{Certificate, PrivateKey, ServerConfig};
use rustls_pemfile::{certs, pkcs8_private_keys};
use std::io::BufReader;
use std::fs::File;

async fn index() -> impl Responder {
    "Hello over mTLS"
}

fn load_rustls_config() -> std::io::Result> {
    // Load server certificate and private key
    let cert_file = &mut BufReader::new(File::open("server-cert.pem")?);
    let key_file = &mut BufReader::new(File::open("server-key.pem")?);

    let cert_chain = certs(cert_file)
        .collect::>>()?;
    let mut keys = pkcs8_private_keys(key_file)
        .collect::>>()?;

    // Load trusted CA for client verification
    let ca_file = &mut BufReader::new(File::open("ca-chain.pem")?);
    let client_certs = certs(ca_file)
        .collect::>>()?;

    let mut config = ServerConfig::builder()
        .with_safe_defaults()
        .with_no_client_auth()
        .with_single_cert(cert_chain, keys.remove(0))?;

    // Enforce client authentication
    config.client_auth_root_subjects = client_certs.into_iter().map(|cert| cert.into()).collect();
    config.verify_peer = true;

    Ok(Arc::new(config))
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let config = load_rustls_config()?;
    let server = HttpServer::new(|| {
        App::new()
            .route("/", web::get().to(index))
            // All routes require mTLS; no open endpoints
    })
    .bind_rustls("0.0.0.0:8443", config)?
    .run();

    server.await
}

2. Explicitly map certificate fields to application identities

Do not rely on implicit certificate subject interpretation. Extract a stable identifier (e.g., a custom Extended Key Usage or a SAN entry) and map it to an internal user or role. Validate this mapping on every request.

use actix_web::{web, HttpRequest, HttpResponse};
use openssl::x509::X509;

// Example extractor that reads the peer certificate from the request extensions
// set by rustls/Actix TLS layer. In practice, you may need to adapt based on
// how your TLS integration exposes peer certs.
async fn get_user_id(req: HttpRequest) -> Result {
    // Retrieve the peer certificate (pseudo-code, adapt to your TLS integration)
    let cert_der = req.extensions()
        .get::>()
         .ok_or_else(|| HttpResponse::forbidden().body("Missing certificate"))?;
    let cert = X509::from_der(cert_der).map_err(|_| HttpResponse::bad_request().body("Invalid cert"))?;

    // Extract a stable identifier, e.g., from SAN or a custom OID
    // This example assumes a custom extension or SAN entry with user ID.
    let user_id = extract_user_id_from_cert(&cert).ok_or_else(|| {
        HttpResponse::forbidden().body("Certificate does not identify a user")
    })?;

    Ok(user_id)
}

fn extract_user_id_from_cert(cert: &X509) -> Option {
    // Implement extraction logic for your chosen identifier,
    // for example, reading a SAN URI or a custom extension.
    // Return None if not found or invalid.
    unimplemented!()
}

3. Apply consistent authorization checks after authentication

Authentication via mTLS must be followed by proper authorization checks (BOLA/IDOR prevention). Always verify that the authenticated identity is allowed to access the requested resource.

use actix_web::{web, HttpRequest, HttpResponse};

async fn view_profile(user_id: web::Path, req: HttpRequest) -> HttpResponse {
    let authenticated_user_id = match get_user_id_from_tls(&req) {
        Ok(id) => id,
        Err(e) => return e,
    };

    // Ensure the authenticated user can only access their own profile
    if authenticated_user_id != *user_id {
        return HttpResponse::forbidden().body("Unauthorized");
    }

    // Proceed to fetch and return the profile
    HttpResponse::ok().body(format!("Profile for {}", user_id))
}

By combining strict mTLS enforcement, explicit identity mapping, and per-request authorization, you mitigate the risk of Broken Authentication in Actix services.