Cache Poisoning in Actix with Basic Auth

Cache poisoning occurs when an attacker causes a shared cache to store malicious content that is then served to other users. In Actix-based applications that use HTTP Basic Authentication, this risk can arise when authorization headers are not properly considered as part of the cache key. If a caching layer (e.g., a CDN, reverse proxy, or in-memory cache) caches responses based only on the request URI and ignores the Authorization header, a response intended for one authenticated user may be served to another user or to unauthenticated requests.

Consider an Actix web service that caches user profile data. If the service uses a naive caching strategy that keys off only the path, an authenticated request from one user could be cached and then replayed to another user who happens to request the same path. Because Basic Authentication credentials are often passed via the Authorization header rather than embedded in the URI, a cache that does not include this header in its key may inadvertently associate the cached response with the wrong identity or with no authentication at all.

In a black-box scan, middleBrick tests such scenarios by submitting authenticated and unauthenticated requests to the same endpoint and comparing responses. When credentials are transmitted in headers and the cache ignores them, the scan can detect inconsistent behavior or exposure of one user’s data to another. This violates the principle of proper authorization separation and can lead to information disclosure, a finding mapped to BOLA/IDOR checks in the 12 security checks. Even when the application itself does not cache responses, intermediaries such as proxies may do so, amplifying the impact of missing cache-key normalization.

Because Basic Authentication sends credentials in an easily decoded header, the exposure risk is elevated when caching is misconfigured. An attacker who can observe or guess valid credentials might leverage caching inconsistencies to confirm usernames or harvest data that should be isolated per identity. Proper remediation requires ensuring that any cache key includes all parts of the request that affect authorization and content, including headers used for authentication.

To prevent cache poisoning in Actix when using HTTP Basic Authentication, ensure that responses are cached with a key that incorporates the effective authorization context. This typically means including the normalized Authorization header or a derived user identifier in the cache key, or avoiding shared caching for authenticated responses unless you can guarantee isolation.

Below is an example of an Actix-web handler that uses Basic Authentication via the actix-http extractor pattern. The handler explicitly reads the Authorization header, validates credentials, and constructs a user-specific cache key. This approach avoids relying on default caching behavior that might ignore headers.

use actix_web::{web, HttpRequest, HttpResponse, Result};
use base64::prelude::*;

async fn user_profile(req: HttpRequest) -> Result {
    // Extract and parse Basic Auth header
    let auth_header = req.headers().get("Authorization")
        .ok_or_else(|| actix_web::error::ErrorUnauthorized("Missing authorization header"))?;
    let auth_str = auth_header.to_str().map_err(|_| actix_web::error::ErrorUnauthorized("Invalid header"))?;
    if !auth_str.starts_with("Basic ") {
        return Err(actix_web::error::ErrorUnauthorized("Unsupported authorization scheme"));
    }
    let encoded = &auth_str[6..];
    let decoded = BASE64_STANDARD.decode(encoded).map_err(|_| actix_web::error::ErrorUnauthorized("Invalid base64"))?;
    let credentials = String::from_utf8(decoded).map_err(|_| actix_web::error::ErrorUnauthorized("Invalid credentials"))?;
    let parts: Vec<&str> = credentials.splitn(2, ':').collect();
    if parts.len() != 2 {
        return Err(actix_web::error::ErrorUnauthorized("Invalid credentials format"));
    }
    let (username, _password) = (parts[0], parts[1]);

    // Construct a cache key that includes the authenticated identity
    let cache_key = format!("profile:{}", username);
    // Here you would integrate with your caching backend, ensuring that responses
    // are stored and retrieved using this user-specific key.
    // For demonstration, we return a success response.
    Ok(HttpResponse::Ok().body(format!("Profile for {}", username)))
}

In production, you should integrate a caching library or middleware that allows you to define custom keys. The important takeaway is that the key must incorporate the authenticated identity derived from the Authorization header, preventing one user’s cached response from being served to another. If your architecture relies on external caches, configure them to vary by the Authorization header or to bypass shared caching for authenticated endpoints.

middleBrick’s scans can help surface inconsistencies between expected and actual cache behavior. By checking authenticated and unauthenticated access patterns, the tool highlights endpoints where cache keys omit authorization context, supporting remediation efforts aligned with secure coding practices and compliance mapping to frameworks such as OWASP API Top 10.