Data Exposure in Actix with Mutual Tls

Data exposure in Actix when mutual TLS is enabled can occur when server-side configuration does not properly validate or forward the client certificate information to application logic. Actix-web provides access to peer certificate data via request extensions, but if endpoints use these values without additional authorization checks, they may unintentionally expose sensitive details such as certificate subject, issuer, or serial number in responses or logs.

During a black-box scan, middleBrick tests unauthenticated endpoints and checks whether certificate metadata is reflected in HTTP responses, error messages, or debug output. Even with mutual TLS in place, an endpoint that returns certificate details (for example, for debugging or informational purposes) can leak identity information that should remain private. The 12 security checks run in parallel, including Data Exposure and Authentication, to detect whether certificate-derived data is being disclosed without proper safeguards.

For example, an Actix handler that reads the peer certificate and includes the subject in a JSON response can expose identity information to any party that can reach the endpoint. If the mutual TLS setup is misconfigured—such as allowing optional client certs or not rejecting missing certificates—this behavior may be reachable without valid client authentication, increasing the risk of information leakage. The scanner cross-references the OpenAPI spec, if available, to determine whether certificate-related parameters are documented as inputs and then validates runtime behavior against those definitions to identify discrepancies that lead to data exposure.

Another scenario involves logging. Actix middleware or application code that logs peer certificate details without redaction can create a data exposure vector, especially if logs are aggregated or accessible to roles that should not see certificate metadata. Because middleBrick tests unauthenticated attack surfaces, it checks whether certificate information appears in error payloads or informational responses, ensuring that sensitive identity attributes are not unintentionally surfaced.

To remediate data exposure risks with mutual TLS in Actix, ensure that peer certificate data is only accessed when necessary and is never reflected to clients unless explicitly required and properly scoped. Use request extensions to retrieve the certificate, apply authorization checks, and avoid including certificate metadata in responses or logs unless essential and safe.

The following example shows a secure Actix-web setup with mutual TLS configuration on the server side and a handler that safely uses client certificate information. This configuration uses native Rust TLS settings; adjust paths and formats to match your certificate authority and deployment environment.

use actix_web::{web, App, HttpServer, Responder, HttpRequest};
use actix_web::http::header::HeaderValue;
use std::sync::Arc;
use openssl::ssl::{SslAcceptor, SslFiletype, SslMethod};

fn create_ssl_acceptor() -> SslAcceptor {
    let mut builder = SslAcceptor::mozilla_intermediate(SslMethod::tls()).expect("Failed to create SSL acceptor");
    builder.set_private_key_file("keys/server.key", SslFiletype::PEM).expect("Failed to set private key");
    builder.set_certificate_chain_file("certs/server.crt").expect("Failed to set certificate chain");
    // Require client authentication
    builder.set_verify(openssl::ssl::SslVerifyMode::PEER | openssl::ssl::SslVerifyMode::FAIL_IF_NO_PEER_CERT, 
        verify_callback);
    builder.build()
}

fn verify_callback(_ssl: &openssl::ssl::Ssl, verify: &mut openssl::ssl::VerifyResult) {
    // Implement custom verification logic if needed, e.g., check certificate against CRL or OCSP
    *verify = openssl::ssl::SslVerifyResult::OK;
}

async fn info_handler(req: HttpRequest) -> impl Responder {
    // Access peer certificate safely and avoid exposing sensitive fields
    if let Some(cert) = req.extensions().get::>() {
        // Perform authorization checks before using cert data
        // For example, map certificate serial or subject to allowed roles
        // Omit sensitive fields from responses; return only necessary non-sensitive indicators
        web::Json(serde_json::json!({ "authenticated": true }))
    } else {
        web::Json(serde_json::json!({ "authenticated": false }))
    }
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let ssl = create_ssl_acceptor();
    HttpServer::new(move || {
        App::new()
            .wrap(ActixTlsData::new(ssl.clone())) // hypothetical middleware to attach cert data
            .route("/info", web::get().to(info_handler))
    })
    .bind_openssl("127.0.0.1:8443", ssl)?
    .run()
    .await
}

In this example, the server requires client certificates and rejects connections without them. The handler retrieves certificate data from request extensions but does not echo certificate fields such as subject or serial number in responses. To further reduce risk, redact or omit metadata in logs and ensure that any debug endpoints exposing certificate details are disabled in production. middleBrick’s scans validate that endpoints requiring mutual TLS do not leak certificate-derived data and that optional client certificate configurations are not inadvertently permitted.