Missing Tls in Actix with Mongodb

A web service built with Actix that connects to a MongoDB backend without Transport Layer Security (TLS) exposes multiple attack surfaces. In this configuration, client requests handled by Actix travel over unencrypted HTTP, and database connections from Actix to MongoDB are also unencrypted if TLS is not enforced. An attacker who can observe or intercept traffic—such as through a compromised local network or a misconfigured proxy—can capture database credentials, session tokens, and query contents sent in cleartext.

Because middleBrick scans the unauthenticated attack surface and tests encryption controls as one of its 12 parallel checks, a deployment with Missing Tls will receive a severe finding in the Encryption category and a corresponding drop in the overall security score. The scan detects that MongoDB connections do not use TLS and that Actix does not enforce HTTPS for incoming requests. These findings map to real-world risks such as credential theft and session hijacking, which are referenced in the OWASP API Top 10 and PCI-DSS requirements for encryption in transit.

In a typical architecture, Actix applications read connection strings from environment variables. If the string begins with mongodb:// instead of mongodb+srv:// or does not include ?tls=true and associated certificate options, the driver opens a plaintext connection. middleBrick flags this pattern during the Data Exposure and Encryption checks, highlighting that data between Actix and MongoDB is not protected. Attack patterns like packet sniffing and man-in-the-middle (MitM) become feasible, enabling an adversary to manipulate or exfiltrate data with relatively low effort.

Additionally, unencrypted Actix endpoints allow an attacker to inject or tamper with requests that influence how MongoDB queries are constructed. Without HTTPS termination at the edge and without encrypted links to the database, there is no assurance of integrity for requests that may include elevated permissions or unsafe operations. This compounds the risk identified by the Authentication and BOLA/IDOR checks, as stolen tokens can be reused directly. middleBrick’s LLM/AI Security checks do not apply here, but the scanner’s Inventory Management and Input Validation findings highlight how missing encryption increases the impact of other weaknesses.

Remediation requires enabling TLS for all MongoDB connections and enforcing HTTPS for all Actix endpoints. Below are concrete, realistic code examples for an Actix application using the official MongoDB Rust driver. These examples assume a MongoDB deployment that supports TLS, such as a self-managed cluster or a cloud provider offering TLS-enabled connections.

First, ensure your connection string uses TLS. With a standard connection string, include tls=true and provide the path to a CA certificate that can verify the server identity. With a MongoDB URI that uses SRV records, use mongodb+srv:// and add ?tls=true along with ?tlsCAFile if your environment does not rely on system trust stores.

use mongodb::{Client, options::ClientOptions};
use actix_web::{web, App, HttpServer, Responder};

async fn get_db_client() -> mongodb::error::Result {
    // Use a TLS-enabled connection string
    let uri = "mongodb+srv://user:[email protected]/?tls=true&tlsCAFile=/path/to/ca.pem";
    let client_options = ClientOptions::parse(uri).await?;
    let client = Client::with_options(client_options)?;
    // Verify the connection is working
    client.list_database_names(None, None).await?;
    Ok(client)
}

async fn health() -> impl Responder {
    "healthy"
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    // Initialize the MongoDB client with TLS
    let db_client = get_db_client().await.expect("Failed to create MongoDB client");

    // Share client via Actix data
    HttpServer::new(move || {
        App::new()
            .app_data(web::Data::new(db_client.clone()))
            .route("/health", web::get().to(health))
    })
    .bind("0.0.0.0:8443")?
    .run()
    .await
}

Second, ensure the Actix server itself listens on HTTPS with a valid certificate. The example below demonstrates binding to an HTTPS address using Rustls certificates. In production, obtain certificates from a trusted CA and rotate them regularly.

use actix_web::{web, App, HttpServer, Responder};
use std::sync::Arc;

async fn health() -> impl Responder {
    "healthy"
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let server = HttpServer::new(|| {
        App::new()
            .route("/health", web::get().to(health))
    })
    .bind_rustls(
        "0.0.0.0:8443",
        rustls::ServerConfig::builder()
            .with_safe_defaults()
            .with_no_client_auth()
            .with_single_cert(
                vec![rustls_pemfile::certs(&mut std::io::BufReader::new(
                    std::fs::File::open("cert.pem").expect("cannot load cert.pem"),
                ))
                .unwrap()
                .into_iter()
                .collect(),
                rustls_pemfile::pkcs8_private_keys(&mut std::io::BufReader::new(
                    std::fs::File::open("key.pem").expect("cannot load key.pem"),
                ))
                .unwrap()
                .remove(0)],
                rustls::sign::CertifiedKey {
                    cert: vec![],
                    key: Arc::new(
                        rustls::PrivateKey(
                            std::fs::read("key.pem").expect("cannot load key.pem"),
                        ),
                    ),
                },
            )
            .expect("invalid server config"),
    )?;
    server.run().await
}

Third, validate that the MongoDB driver verifies the server certificate chain. The default driver behavior should reject self-signed certificates unless explicitly configured to trust them, which should be avoided in production. middleBrick’s Encryption check will confirm that TLS is enforced and that the cipher suites are strong, while the Encryption check will highlight any remaining plaintext pathways.