HIGH missing tlsactixbasic auth

Missing Tls in Actix with Basic Auth

Missing Tls in Actix with Basic Auth — how this specific combination creates or exposes the vulnerability

Transport Layer Security (TLS) is the network-layer control that protects HTTP traffic in transit. When an Actix web service exposes endpoints that require HTTP Basic Authentication and does so without TLS, credentials are transmitted as base64-encoded plaintext across the network. base64 is not encryption; it is an encoding, so any observer who can intercept the packets can recover the username and password in clear text.

In a typical Actix web application, credentials are often passed via the Authorization: Basic <base64> header. Without TLS, an on-path attacker can perform session hijacking or credential theft by sniffing network traffic from Wi‑Fi eavesdropping, compromised routers, or malicious insiders on the same network. Because Basic Auth sends the secret with every request, the exposure is persistent across the session lifetime, not limited to a single login handshake.

middleBrick scans unauthenticated attack surfaces and flags Missing Tls as a high-severity finding when a service accepts cleartext HTTP requests that include authentication. When combined with Basic Auth, this becomes a critical risk because the authentication material itself is exposed. Attack patterns such as credential sniffing and session replay are well documented in the OWASP API Security Top 10 and commonly map to items like Broken Object Level Authorization when compromised credentials are used to escalate access.

Even if the service otherwise implements reasonable per-request checks, lacking TLS undermines those controls by breaking the confidentiality of the transport. Regulatory frameworks such as PCI-DSS and GDPR require protection of credentials in transit, and the absence of TLS can result in noncompliance. middleBrick’s LLM/AI Security checks do not apply here, but the scanner’s authentication and data exposure tests are designed to detect cleartext credential transmission and surface the issue with prioritized remediation guidance.

For context, consider a publicly reachable Actix endpoint that validates permissions using role claims decoded from the credentials. An attacker who recovers the credentials can forge valid requests, bypassing intended authorization boundaries. This illustrates why Missing Tls must be treated as a high priority when Basic Auth is in use, regardless of whether the endpoint also employs additional application-level checks.

Basic Auth-Specific Remediation in Actix — concrete code fixes

To remediate Missing Tls when using HTTP Basic Authentication in Actix, enforce TLS at the load balancer or application level and ensure the server rejects cleartext HTTP. Below is a minimal but complete Actix example that uses middleware to require HTTPS and provides a secure Basic Auth implementation.

use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use actix_web::http::header::HeaderValue;
use actix_web::dev::ServiceRequest;
use actix_web::error::ErrorUnauthorized;
use actix_web_httpauth::extractors::basic::BasicAuth;
use std::env;

async fn auth_middleware(req: ServiceRequest) -> Result {
    // Reject HTTP (non-TLS) requests early
    let connection = req.connection_info().clone();
    if !connection.secure() {
        return Err(ErrorUnauthorized("HTTPS is required"));
    }
    Ok(req)
}

async fn protected_route(auth: BasicAuth) -> impl Responder {
    // Validate credentials against a secure store; avoid logging the password
    if authenticate_user(auth.user_id(), auth.password()) {
        HttpResponse::Ok().body("Authenticated and authorized")
    } else {
        HttpResponse::Unauthorized().body("Invalid credentials")
    }
}

fn authenticate_user(username: &str, password: &str) -> bool {
    // Use constant-time comparison and a secure password store in production
    // Placeholder logic; integrate with your identity provider
    username == "admin" && password == "S3cur3P@ss!"
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    // Enforce HTTPS via server configuration or reverse proxy.
    // In production, terminate TLS at the load balancer and ensure
    // Actix only receives secure traffic (e.g., X-Forwarded-Proto=https).
    HttpServer::new(|| {
        App::new()
            .wrap_fn(|req, srv| {
                // Middleware to reject non-TLS requests
                Box::pin(async move {
                    let connection = req.connection_info().clone();
                    if !connection.secure() {
                        return Err(ErrorUnauthorized("HTTPS is required").into());
                    }
                    srv.call(req).await
                })
            })
            .route("/api/secure", web::get().to(protected_route))
    })
    .bind_rustls("0.0.0.0:8443", rustls::ServerConfig::builder()
        .with_safe_defaults()
        .with_no_client_auth()
        .with_single_cert(
            vec![include_bytes("../certs/server.cert").to_vec()],
            include_bytes!("../certs/server.key").to_vec(),
        )
        .map_err(|err| eprintln!("Rustls error: {:?}", err))?
    )?
    .run()
    .await
}

Key points in this remediation:

  • TLS enforcement: The middleware checks connection.secure() and rejects cleartext HTTP, ensuring all traffic is encrypted in transit.
  • Secure binding: The server uses bind_rustls with a certificate and private key, demonstrating how to enable native TLS in Actix. In production, you may terminate TLS at a load balancer and configure Actix to accept only trusted secure connections.
  • Basic Auth handling: The example uses actix-web-httpauth to extract and validate Basic credentials. Avoid logging passwords and prefer constant-time comparison against a securely stored hash.
  • Defense in depth: Combine TLS with strong password policies, secure storage (e.g., bcrypt), and additional authorization checks to reduce the impact of any residual risks.

middleBrick’s CLI can verify that TLS is enforced by scanning the endpoint and checking for the Missing Tls finding. If you are using the GitHub Action, you can fail builds when the scanner detects cleartext authentication endpoints. The MCP Server allows you to trigger scans directly from your IDE while developing Actix services, helping you catch Missing Tls early.

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

Can I use Basic Auth over TLS safely in Actix?
Yes, you can use HTTP Basic Authentication over TLS safely, provided TLS is correctly configured and enforced. Ensure the server rejects cleartext HTTP and that your certificate and private key are properly managed. Even with TLS, consider stronger alternatives such as token-based authentication where appropriate.
How does middleBrick detect Missing Tls in Actix services that use Basic Auth?
middleBrick sends unauthenticated requests to the endpoint and inspects whether responses are served over cleartext HTTP and whether authentication challenges expose credentials in an unencrypted form. It flags Missing Tls when TLS is not observed, and highlights findings related to authentication and data exposure with severity and remediation guidance.