Cache Poisoning in Actix (Rust)

Cache poisoning occurs when an attacker manipulates cached responses so that subsequent users receive malicious or incorrect data. In Actix applications written in Rust, this risk arises when responses are cached based on insufficient request validation, allowing an attacker to inject a crafted query or header that changes the cache key. Because Actix often uses per-request data to construct cache keys, unsafe handling of untrusted input can cause the application to cache a poisoned response and serve it to other users.

Actix-web does not provide built-in HTTP caching; developers typically introduce caching at the application layer or via middleware. When caching is implemented naively—such as using the raw request path, selected headers, or unvalidated query parameters as the cache key—an attacker can control or influence those elements. For example, if the cache key includes the Host header or a user-controlled X-Forwarded-Host value without normalization, an attacker can poison the cache for shared cache infrastructure or for other users of the same origin.

In Rust, memory-safety guarantees prevent many classes of memory corruption, but they do not prevent logic flaws such as cache poisoning. An Actix handler that deserializes user input into a struct and uses a field directly in cache logic can introduce a vulnerability. Consider a handler that uses a query parameter to select a product ID and caches the response by the full URL. If the URL is used verbatim as the cache key, an attacker can request paths like /products/1?callback=evil and trick the cache into storing a response intended for a different context. This becomes critical when the cached response includes sensitive data or includes unsafe content that later reaches other users.

Real-world attack patterns mirror SSRF and injection concepts, but in a caching context, the impact is the distribution of malicious content or the disclosure of information. Unlike runtime request handling, cached responses bypass handler logic, which means security controls inside the handler may not be applied. Therefore, validation and normalization must happen before caching decisions are made. The scanner’s checks for Input Validation and Data Exposure are relevant here because they surface places where untrusted data reaches cache-sensitive code paths without canonicalization.

Additionally, Actix applications that integrate with external services or use reverse proxies may inadvertently incorporate request metadata into cache keys. If headers such as Authorization or X-Forwarded-Proto are included without redaction, attackers may probe for differences that affect caching behavior. The scanner’s Authentication and Property Authorization checks help identify whether authorization-sensitive data leaks into cache logic, which would compound the poisoning impact by exposing user-specific content to unauthorized users.

To mitigate cache poisoning in Actix with Rust, ensure cache keys are derived from safe, normalized, and attacker-independent values. Avoid using raw user input, headers, or the full URL directly. Instead, explicitly select and sanitize the parts of the request that should influence caching, such as a validated resource identifier, and strip or ignore parameters that do not affect the response content.

Below is a safe pattern for an Actix handler that caches product details. The example uses a strongly typed extractor for query parameters, validates the input, and constructs a canonical cache key that excludes volatile or attacker-controlled metadata.

use actix_web::{web, HttpResponse, Result};
use serde::Deserialize;

#[derive(Deserialize)]
struct ProductQuery {
    id: u64,
    // Explicitly ignore fields that must not affect caching
    #[serde(rename = "callback")]
    _callback: Option, // ignored
}

async fn get_product(
    query: web::Query,
    // Assume `cache_service` is an application-level cache interface
    cache_service: web::Data<CacheService>,
) -> Result<HttpResponse> {
    let product_id = query.id;
    // Canonical cache key based only on validated business identifier
    let cache_key = format!("product:{}", product_id);

    if let Some(cached) = cache_service.get(&cache_key) {
        return Ok(HttpResponse::Ok()
            .content_type("application/json")
            .body(cached));
    }

    // Produce response (omitted business logic for brevity)
    let response_body = serde_json::to_string(&ProductResponse { id: product_id, name: "Example" })?;
    cache_service.insert(cache_key, response_body.clone());
    Ok(HttpResponse::Ok()
        .content_type("application/json")
        .body(response_body))
}

This approach ensures that fields like callback or other non-essential parameters are ignored, preventing an attacker from altering the cache key via query string manipulation. The cache key is derived solely from the validated numeric ID, which cannot be abused to inject alternate paths or hostnames.

When caching at the HTTP layer (e.g., via reverse proxy rules), apply header normalization or exclusion before the request reaches Actix. Strip or hash headers such as Host, X-Forwarded-Host, and Authorization if they must be considered, or remove them from the key construction entirely. The scanner’s checks for BFLA/Privilege Escalation and Property Authorization can highlight places where authorization-sensitive headers are improperly influencing cache behavior.

For applications that must vary cache behavior by tenant or user segment, use a controlled mapping (e.g., a verified tenant identifier from a secure session or token) rather than raw headers. Combine this with strict input validation: accept only known-safe values, enforce length and character rules, and reject unexpected or malformed inputs before they reach cache logic. The scanner’s Input Validation checks help surface endpoints where such validation is missing.

Finally, monitor cached responses for unexpected variance and implement cache invalidation strategies that rely on trusted internal events rather than client-controlled data. By combining typed extractors, explicit key construction, and header sanitization, Rust’s safety guarantees can be leveraged to prevent cache poisoning in Actix applications without introducing runtime regressions.