Timing Attack in Actix with Bearer Tokens

A timing attack in Actix that involves Bearer tokens occurs when the comparison of a provided token against an expected value does not execute in constant time. In an HTTP API built with Actix-web, authentication often happens in middleware or an extractor that reads an Authorization header, extracts the Bearer token, and compares it to a stored value. If the comparison short-circuits on the first mismatching character, an attacker can learn information about the expected token by measuring response times. Longer prefixes that match will take slightly longer to evaluate, and statistical aggregation of many requests can eventually reveal the full token or confirm partial knowledge.

This vulnerability is tightly coupled with how tokens are stored and compared. For example, using a simple string equality check in Rust is unsafe for secrets because Rust’s default string comparison does not guarantee constant-time execution. In Actix, a typical but risky pattern is to extract the token in a handler or guard and compare it directly with a hardcoded or database-retrieved secret. If the comparison leaks timing differences, an attacker who can make authenticated requests (or observe timing differences over the network) can gradually infer the token. This becomes more impactful when tokens are long-lived or reused across multiple endpoints, effectively turning a secret comparison into a side-channel that undermines the purpose of bearer token authentication.

Real-world attack patterns mirror those described in OWASP API Top 10 and can be referenced alongside concrete examples. A common mistake is to write something like if auth_header == expected_token { /* allow */ } without considering timing safety. In practice, an attacker can send tokens that progressively match the known prefix and observe whether response times increase, indicating a longer matching prefix. While Actix does not inherently introduce this flaw, application code written on top of Actix can expose it. Mitigations must be applied at the comparison layer, using constant-time equality functions, and complemented by broader protections such as rate limiting and short token lifetimes to reduce the feasibility of network-based timing measurements.

Additional context from the broader API security checklist reinforces the risk. Timing-related weaknesses often coexist with other issues such as insufficient input validation and missing rate limiting, which can amplify an attacker’s ability to probe the system. For instance, without rate limiting, an attacker can send many requests to measure timing differences with less suspicion. The LLM/AI Security module of middleBrick specifically tests for behaviors that could lead to information leakage, including patterns that may expose timing differentials through repeated operations. Although middleBrick does not fix the implementation, its findings can highlight insecure comparison practices and guide developers toward remediation.

To illustrate the insecure pattern, consider this example token extraction in Actix:

use actix_web::{web, HttpRequest, HttpResponse};

fn insecure_check(req: &HttpRequest, expected: &str) -> bool {
    if let Some(auth) = req.headers().get("Authorization") {
        if let Ok(auth_str) = auth.to_str() {
            if auth_str.starts_with("Bearer ") {
                let token = auth_str.trim_start_matches("Bearer ").trim();
                return token == expected; // vulnerable to timing attacks
            }
        }
    }
    false
}

This snippet demonstrates the exact problem: the equality check on the last line can short-circuit on the first differing byte. In a real deployment, the expected value might come from a database or configuration, and the handler would allow access only if the comparison succeeds. An attacker who can observe timing differences can iteratively guess the token byte by byte. Defensive code must replace such comparisons with constant-time alternatives and ensure that tokens are treated as sensitive secrets throughout their lifecycle.

Remediation focuses on replacing naive equality checks with constant-time comparison and hardening the surrounding authentication flow. In Rust, the subtle crate provides utilities such as ConstantTimeEq for byte-by-byte comparisons that do not branch on secret data. When handling Bearer tokens in Actix, you should extract the token, convert it to bytes, and compare it against the stored token bytes using a constant-time function. This ensures that an attacker cannot infer partial matches from response timings.

Additionally, you should minimize the exposure of the token in logs and error messages, enforce short token lifetimes, and apply rate limiting to reduce the practicality of timing probes. Defense in depth also includes validating the format of the Authorization header strictly and rejecting malformed requests early to avoid leaking information through different code paths. The following example demonstrates a safer approach within an Actix-web extractor or middleware.

Here is a secure Bearer token validation example using constant-time comparison in Actix:

use actix_web::{dev::ServiceRequest, Error};
use subtle::ConstantTimeEq;

const EXPECTED_TOKEN_BYTES: &[u8] = b"supersecrettoken123"; // store securely, e.g., from env

pub fn validate_bearer_token(req: &ServiceRequest) -> Result {
    const PREFIX: &[u8] = b"Bearer ";
    let auth_header = req.headers().get("Authorization")
        .and_then(|v| v.to_str().ok())
        .map(|s| s.as_bytes())
        .ok_or_else(|| actix_web::error::ErrorUnauthorized("Invalid authorization header"))?;

    if auth_header.len() < PREFIX.len() {
        return Ok(false);
    }

    if !auth_header[..PREFIX.len()].ct_eq(PREFIX).into() {
        return Ok(false);
    }

    let token = &auth_header[PREFIX.len()..];
    let ok = token.ct_eq(EXPECTED_TOKEN_BYTES).into() & (token.len() == EXPECTED_TOKEN_BYTES.len());
    Ok(ok)
}

This code uses ct_eq from the subtle crate to compare bytes in constant time. It first checks the "Bearer " prefix in constant time, then compares the token portion against the expected bytes with equal length checks combined with constant-time equality. This approach prevents timing leaks at each step. Note that the actual storage and retrieval of EXPECTED_TOKEN_BYTES should be handled securely, avoiding hardcoding in production code.

For broader integration, you can implement this check in an Actix guard or middleware. Below is an example of a guard that uses the secure validation function:

use actix_web::{guard, web, HttpRequest, HttpResponse};
use actix_web::dev::ServiceRequest;
use actix_web::error::ErrorUnauthorized;

pub fn bearer_guard(expected_bytes: &'static [u8]) -> guard::Guard {
    guard::Guard::new(move |req: &ServiceRequest| {
        validate_bearer_token(req).unwrap_or(false)
    })
}

// Usage in route definition:
// App::new().service(
//     web::resource("/admin")
//         .guard(bearer_guard(EXPECTED_TOKEN_BYTES))
//         .route(web::get().to(secure_handler)),
// );

These examples illustrate how to adapt your Actix services to use constant-time comparisons for Bearer tokens. Complementary measures such as rotating tokens, binding tokens to scopes, and monitoring for abnormal request patterns further reduce risk. middleBrick’s scans can surface timing-related anomalies by correlating findings across authentication, input validation, and rate limiting checks, helping you prioritize remediation efforts.