HIGH missing tlsaxumcockroachdb

Missing Tls in Axum with Cockroachdb

Missing Tls in Axum with Cockroachdb — how this specific combination creates or exposes the vulnerability

When an Axum service communicates with CockroachDB without TLS, credentials, queries, and result sets can traverse the network in cleartext. This is particularly risky in distributed or cloud environments where traffic may pass through shared infrastructure. middleBrick scans detect this as a Data Exposure finding under the Encryption check, highlighting that unencrypted database channels can expose sensitive data to interception.

In a typical Axum application using a connection pool to CockroachDB, if the connection string omits sslmode=require (or an equivalent enforcing encryption), the driver may establish a plaintext TCP connection. An attacker who can observe or manipulate network traffic—such as in a compromised container network or via a misconfigured load balancer—can capture authentication tokens, session cookies, or even application-level data. This scenario maps to real-world attack patterns like credential sniffing and man-in-the-middle (MITM) within the OWASP API Top 10 and broader compliance frameworks such as PCI-DSS and SOC2.

For example, a connection string like postgresql://user:password@cockroachdb.example:26257/mydb without TLS enforcement leaves the database user and password vulnerable. middleBrick’s LLM/AI Security checks do not apply here, but the scanner’s Encryption and Data Exposure tests validate whether traffic to and from CockroachDB is protected. If TLS is missing, the findings will include guidance to enforce encrypted connections and validate server certificates to prevent interception.

Cockroachdb-Specific Remediation in Axum — concrete code fixes

To secure Axum applications connecting to CockroachDB, enforce TLS by using sslmode=require (or stricter modes like verify-full when you want full certificate validation). The following example shows a typical Axum handler using bb8 and tokio-postgres with a secure connection string and proper Rust async runtime setup.

use axum::{routing::get, Router};
use bb8::Pool;
use bb8_postgres::PostgresConnectionManager;
use tokio_postgres::NoTls;
use std::net::SocketAddr;

// UNSAFE: NoTls used for illustration—replace with proper TLS in production
async fn insecure_handler() -> &'static str {
    "Avoid NoTls in production; use TlsConnect from postgres-openssl or rustls"
}

#[tokio::main]
async fn main() {
    // Secure connection string for CockroachDB with TLS enforced
    let config = "postgresql://myuser:mypassword@cockroachdb.example:26257/mydb?sslmode=require";
    let manager = PostgresConnectionManager::new_from_stringlike(config, NoTls).expect("valid connection string");
    let pool: Pool> = bb8::Pool::builder().build(manager).await.unwrap();

    let app = Router::new().route("/health", get(|| async { "ok" }));
    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

For stronger security, use postgres-openssl or rustls to provide certificate verification. Below is an example with postgres-openssl to require and validate the CockroachDB server certificate.

use axum::Router;
use bb8::Pool;
use bb8_postgres::PostgresConnectionManager;
use openssl::ssl::{SslConnector, SslMethod, SslVerifyMode};
use postgres_openssl::MakeTlsConnector;
use tokio_postgres::NoTls;

fn make_tls_connector() -> MakeTlsConnector {
    let mut builder = SslConnector::builder(SslMethod::tls_client()).unwrap();
    builder.set_verify(SslVerifyMode::PEER | SslVerifyMode::FAIL_IF_NO_PEER_CERT);
    // Load trusted CA certificates (e.g., CockroachDB root CA)
    builder.set_ca_file("/path/to/ca.pem").expect("valid CA file");
    MakeTlsConnector::new(builder.build())
}

async fn secure_handler() -> &'static str {
    "TLS with certificate verification enabled"
}

#[tokio::main]
async fn main() {
    let config = "postgresql://myuser:mypassword@cockroachdb.example:26257/mydb?sslmode=verify-full";
    let tls = make_tls_connector();
    let manager = PostgresConnectionManager::new_from_stringlike(config, tls).expect("valid connection string with TLS");
    let pool: Pool> = bb8::Pool::builder().build(manager).await.unwrap();

    let app = Router::new().route("/secure", get(|| async { "secure route" }));
    let addr = SocketAddr::from(([127, 0, 0, 1], 3001));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

Ensure the CockroachDB node certificates are available to the application and that the hostname in the certificate matches the server hostname used in the connection string. middleBrick’s OpenAPI/Swagger and runtime checks can validate whether the submitted endpoint enforces encryption, and its per-category breakdown will surface missing TLS alongside actionable remediation guidance.

Related CWEs: encryption

CWE IDNameSeverity
CWE-319Cleartext Transmission of Sensitive Information HIGH
CWE-295Improper Certificate Validation HIGH
CWE-326Inadequate Encryption Strength HIGH
CWE-327Use of a Broken or Risky Cryptographic Algorithm HIGH
CWE-328Use of Weak Hash HIGH
CWE-330Use of Insufficiently Random Values HIGH
CWE-338Use of Cryptographically Weak PRNG MEDIUM
CWE-693Protection Mechanism Failure MEDIUM
CWE-757Selection of Less-Secure Algorithm During Negotiation HIGH
CWE-261Weak Encoding for Password HIGH

Frequently Asked Questions

How does middleBrick detect missing TLS in an API that uses CockroachDB?
middleBrick performs unauthenticated scans that inspect whether API endpoints and backend services enforce encryption for data in transit. For database-backed APIs, findings are reported under the Encryption and Data Exposure checks when connections (e.g., to CockroachDB) do not require TLS, indicating cleartext transmission risks.
Can middleBrick fix missing TLS configurations in Axum applications?
middleBrick detects and reports missing TLS with remediation guidance, but it does not automatically fix configurations. Developers should update connection strings to include sslmode=require or stricter modes and validate server certificates, then rescan to confirm the issue is resolved.