Missing Tls in Axum with Mongodb

When an Axum service communicates with a MongoDB backend without TLS, credentials, session tokens, and query data can traverse the network in cleartext. This is especially risky in Axum applications where connection strings or environment-based configuration may inadvertently omit mongodb:// in favor of an unencrypted mongodb:// URI. An attacker on the same network or path can intercept these transmissions, leading to unauthorized database access and potential data breaches.

In a typical Axum handler, if the MongoDB client is initialized with a non-TLS URI and the server does not enforce outgoing encryption, the client may succeed in establishing a cleartext connection. middleBrick will flag this as a data exposure risk, noting that unencrypted database traffic violates secure transport expectations. This misconfiguration also intersects with other checks such as authentication weaknesses (e.g., default or missing credentials) and input validation gaps, amplifying the overall risk profile. The scanner highlights that without TLS, sensitive operations like authentication and data retrieval are exposed, which can map to OWASP API Top 10 A02:2023 (Cryptographic Failures) and relevant regulatory controls.

middleBrick’s unauthenticated scan detects these issues by observing that the endpoint accepts connections without enforcing encrypted channels and by correlating the runtime behavior with OpenAPI specifications that may declare security schemes but omit transport-layer requirements. The tool does not assume internal architecture; it reports the observable absence of TLS on the API surface and any associated backend linkage, providing prioritized findings with remediation guidance.

To remediate missing TLS when Axum communicates with MongoDB, ensure the MongoDB URI uses mongodb+srv:// or mongodb:// with explicit TLS parameters, and configure the Rust driver to enforce encrypted connections.

Example: Secure MongoDB connection setup in Axum

use mongodb::{Client, options::ClientOptions};
use axum::{routing::get, Router};

async fn build_client() -> mongodb::error::Result {
    // Use a TLS-enabled connection string.
    // For Atlas, prefer mongodb+srv:// which enforces TLS.
    let uri = "mongodb+srv://user:[email protected]/?tls=true&tlsAllowInvalidCertificates=false";
    let mut client_options = ClientOptions::parse(uri).await?;
    // Enforce TLS and set a reasonable timeout.
    client_options.tls = Some(mongodb::options::TlsOptions {
        enabled: Some(true),
        allow_invalid_certificates: Some(false),
        allow_invalid_hostnames: Some(false),
    });
    Client::with_options(client_options)
}

#[tokio::main]
async fn main() -> mongodb::error::Result<()> {
    let client = build_client().await?;
    let db = client.database("secure_db");

    let app = Router::new().route("/health", get(|| async { "ok" }));
    // Use `db` in your handlers, passing a shared reference or state.
    axum::Server::bind(&("0.0.0.0:3000").parse().unwrap())
        .serve(app.into_make_service())
        .await
        .unwrap();
    Ok(())
}

If using a standard mongodb:// URI, explicitly include query parameters to enforce TLS:

let uri = "mongodb://user:password@host1:27017,host2:27017/?tls=true&tlsCertificateKeyFile=/path/to/client.pem";

In the GitHub Action, set the connection string as a secret and reference it in workflow files to ensure CI/CD pipelines validate TLS usage. The Pro plan’s continuous monitoring can alert you if a scan later detects missing TLS on any tracked API or backend linkage. For rapid verification, the CLI command middlebrick scan <url> can be used in scripts to confirm that TLS is enforced on the public surface while the MCP Server enables AI coding assistants to surface these concerns during development.