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_rustlswith 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-httpauthto 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 ID | Name | Severity |
|---|---|---|
| CWE-319 | Cleartext Transmission of Sensitive Information | HIGH |
| CWE-295 | Improper Certificate Validation | HIGH |
| CWE-326 | Inadequate Encryption Strength | HIGH |
| CWE-327 | Use of a Broken or Risky Cryptographic Algorithm | HIGH |
| CWE-328 | Use of Weak Hash | HIGH |
| CWE-330 | Use of Insufficiently Random Values | HIGH |
| CWE-338 | Use of Cryptographically Weak PRNG | MEDIUM |
| CWE-693 | Protection Mechanism Failure | MEDIUM |
| CWE-757 | Selection of Less-Secure Algorithm During Negotiation | HIGH |
| CWE-261 | Weak Encoding for Password | HIGH |