Missing Tls in Actix with Bearer Tokens

When an Actix web service transmits Bearer Tokens over unencrypted HTTP, the tokens are exposed in cleartext across the network. This specific combination—unencrypted transport with bearer-based authorization—violates transport confidentiality and enables several well-known attack patterns, including token interception and session hijacking.

In practice, an attacker on the same network segment, or an adversary positioned between the client and server (for example via a compromised Wi‑Fi access point or a malicious proxy), can capture the Authorization header. Because the token is a bearer credential, possession of the token is typically sufficient to impersonate the associated identity for the scope and lifetime encoded in the token. This maps directly to the BOLA/IDOR and Data Exposure checks in middleBrick, and it is a common finding when scanning Actix endpoints that lack TLS.

Even when token handling in application code appears correct (e.g., validating token format and scope), missing transport encryption undermines those protections. For example, if an Actix route such /api/me expects a Bearer Token in the header and returns profile data, an unencrypted request allows interception of both the token and the sensitive profile response, which may contain PII. This scenario aligns with the OWASP API Top 10:2023 A02 — Broken Authentication and A05 — Security Misconfiguration, and it can be surfaced by middleBrick’s unauthenticated scan, which tests the exposed attack surface without credentials.

Moreover, missing TLS can facilitate secondary risks such as SSRF when token leakage occurs in logs or error messages that are transmitted unencrypted. middleBrick’s Data Exposure and SSRF checks look for indicators that sensitive information, including bearer tokens, might leave the protected channel. Because middleBrick scans in 5–15 seconds and checks 12 security controls in parallel, it can quickly highlight the absence of transport encryption alongside authorization mechanisms that rely on bearer tokens.

To remediate missing TLS in Actix when using Bearer Tokens, enforce HTTPS across the entire application and ensure that tokens are only accepted over encrypted connections. Below are concrete, realistic code examples for an Actix web service that require secure transport and validate Bearer Tokens correctly.

Enforce HTTPS in Actix

Use Actix’s native support for TLS by configuring an HTTPS server with a certificate and private key. This ensures all traffic, including Authorization headers, is encrypted in transit.

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 std::sync::Arc;

async fn validate_bearer(req: ServiceRequest, credentials: Arc<str>) -> Result<ServiceRequest, (actix_web::Error, ServiceRequest)> {
    let auth_header = req.headers().get("Authorization");
    match auth_header {
        Some(header_value) => {
            let header_str = header_value.to_str().unwrap_or("");
            if header_str.starts_with("Bearer ") {
                let token = &header_str[7..];
                if token == credentials.as_ref() {
                    return Ok(req);
                }
            }
            Err((ErrorUnauthorized("Invalid or missing Bearer Token"), req))
        }
        None => Err((ErrorUnauthorized("Missing Authorization header"), req)),
    }
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let credentials = Arc::new("your-secure-token-here");

    HttpServer::new(move || {
        App::new()
            .wrap_fn(|req, srv| {
                let credentials = credentials.clone();
                async move {
                    validate_bearer(req, credentials).and_then(|req| srv.call(req).await)
                }
            })
            .route("/api/me", web::get().to(|| async { HttpResponse::Ok().body("Secure profile data") }))
    })
    .bind_openssl("127.0.0.1:8443", {
        use openssl::ssl::{SslAcceptor, SslFiletype, SslMethod};
        let mut builder = SslAcceptor::mozilla_intermediate(SslMethod::tls()).unwrap();
        builder.set_private_key_file("key.pem", SslFiletype::PEM).unwrap();
        builder.set_certificate_chain_file("cert.pem").unwrap();
        builder.build()
    })?
    .run()
    .await
}

The example above binds the server to an SSL acceptor using a certificate and private key, ensuring that all communication occurs over TLS. The bearer token validation middleware checks for the presence and correctness of the Authorization header before allowing access to protected routes.

Reject Non‑TLS Requests

Optionally, configure the service to reject cleartext HTTP requests entirely. This can be done by not binding an HTTP listener or by returning an error for non‑TLS connections.

// Example: Only bind HTTPS and return an error for HTTP attempts
HttpServer::new(move || {
    App::new()
        .route("/api/secure", web::get().to(|| async { HttpResponse::Ok().body("TLS required") }))
})
.bind_openssl("0.0.0.0:8443", ssl_builder)
.unwrap()
.run()
.await

In addition to code changes, adopt middleBrick’s CLI to verify that your endpoints enforce TLS. Running middlebrick scan <url> against your Actix service will surface missing transport encryption and provide prioritized findings with remediation guidance, helping you address issues before they are exposed in production.