Cache Poisoning in Actix

Cache poisoning in Actix typically arises from improper handling of HTTP headers or query parameters that influence caching behavior without proper validation. Actix-web, as a high-performance web framework, relies on developers to correctly set cache-related headers via HttpResponse builders or middleware. A common vector is the Cache-Control or Age header being injected via user-controlled input, such as a query parameter or header, which then gets reflected in the response. For example, if an Actix endpoint uses web::Query to extract a parameter and directly inserts it into a Cache-Control header without sanitization, an attacker could inject directives like max-age=31536000 to cache a malicious response indefinitely.

Another Actix-specific pattern involves the use of actix-web::middleware::Cache or custom caching layers where the cache key is derived from unsanitized parts of the request, such as the Path or Query. If the cache key includes user input that can be manipulated (e.g., a user_id in the path that is not validated), an attacker could poison the cache entry for a legitimate user by crafting a request with a malicious value, causing subsequent users to receive the poisoned response.

Real-world parallels include CVE-2021-44790 in Apache HTTP Server, where improper header handling led to cache poisoning. In Actix, similar risks exist when developers manually construct responses using HttpResponse::build() and insert raw input into headers. For instance, a route that reflects a Referer header into Link or Cache-Control without validation can be exploited to poison shared caches like CDNs or reverse proxies.

Detecting cache poisoning in Actix requires analyzing how user input flows into cache-relevant headers or cache key generation. middleBrick identifies this by scanning for patterns where unauthenticated input influences Cache-Control, Expires, Age, or custom cache keys without validation. During its black-box scan, middleBrick sends probes with payloads designed to inject cache directives (e.g., ?cache-control=max-age%3D31536000) and monitors responses for reflection of these parameters in headers.

Specifically, middleBrick’s Input Validation and Data Exposure checks test for header injection via query parameters, paths, and headers. For Actix applications, it examines endpoints using web::Query, web::Path, or web::Header extractors that feed into response builders. If a parameter appears in a Cache-Control header in the response, middleBrick flags it as a potential cache poisoning vector with medium to high severity, depending on whether the injected directive persists in cached responses (verified via follow-up requests).

Additionally, middleBrick’s SSRF and Inventory Management checks help detect if cached responses are being served from unintended sources, indicating possible poisoning. For example, if a scan reveals that a request with a malicious Host header poisons a cache entry that then serves internal endpoints to external users, this is caught under Data Exposure or SSRF categories. The scanner does not assume internal architecture but observes behavioral changes in response caching based on input manipulation.

Remediating cache poisoning in Actix centers on strict input validation and avoiding the use of unsanitized user input in cache-related headers or cache key generation. Developers should never directly insert query parameters, path values, or headers into Cache-Control, Expires, or similar headers without validation. Instead, use allow-lists for acceptable values or derive cache keys from validated, application-specific identifiers.

For example, consider a vulnerable Actix endpoint that reflects a theme query parameter into Cache-Control:

use actix_web::{get, web, HttpResponse, Responder};

#[get("/profile")]
async fn profile(theme: web::Query<std::collections::HashMap<String, String>>) -> impl Responder {
    let theme_val = theme.get("theme").unwrap_or(&"light".to_string());
    HttpResponse::Ok()
        .header("Cache-Control", format!("max-age=3600, theme={}", theme_val)) // VULNERABLE
        .body("Profile page")
}

An attacker could send ?theme=malicious%3Bmax-age%3D31536000 to inject arbitrary cache directives. The fix is to validate the theme value against an allow-list:

use actix_web::{get, web, HttpResponse, Responder};

#[get("/profile")]
async fn profile(theme: web::Query<std::collections::HashMap<String, String>>) -> impl Responder {
    let theme_val = theme.get("theme").unwrap_or(&"light".to_string());
    // Validate against allow-list
    let safe_theme = match theme_val.as_str() {
        "light" | "dark" | "system" => theme_val,
        _ => "light",
    };
    HttpResponse::Ok()
        .header("Cache-Control", format!("max-age=3600, theme={}", safe_theme)) // SAFE
        .body("Profile page")
}

Similarly, when generating cache keys (e.g., in custom middleware), avoid using raw path or query values. Instead, use authenticated user IDs or validated resource identifiers. For instance, if caching user profiles, key the cache by user_id from session or token (after validation), not by a path parameter like username that could be manipulated.

Leverage Actix’s type-safe extractors: use web::Path<Uuid> for UUID paths to ensure only valid values are processed, reducing injection risk. Always treat input as untrusted and validate before using it in any security-sensitive context, including caching directives.