Cache Poisoning in Actix with Api Keys

Cache poisoning occurs when an attacker manipulates cached responses so that subsequent users receive malicious or incorrect data. In Actix-based services that rely on API keys for authorization, a common misconfiguration is using request attributes that vary per client—such as the API key value or key ID—as part of the cache key while also caching responses that include user-specific or sensitive data. If the caching layer treats requests with different API keys as distinct cache entries but does not segregate content strictly, an attacker who can observe or influence one client’s cached response might cause sensitive data to be stored under a key they can later request.

Consider an Actix web service that caches upstream or database responses to reduce latency. If the cache key includes the API key header directly and the cached response contains data not intended for all clients, two issues arise:

• The same endpoint may return different data depending on which API key is used, increasing the risk of information leakage between clients.
• If the service does not validate whether the requesting client is authorized for the cached data, a client might inadvertently receive another client’s data, violating isolation boundaries.

Real-world examples include caching personalized responses (e.g., account details or transaction history) without ensuring that the cache key incorporates user or tenant identifiers in a way that prevents cross-client contamination. In an Actix application, this can happen when routes use a generic caching wrapper that hashes the full request URI and selected headers (such as X-API-Key) but does not enforce tenant-aware scoping or validate that the requesting API key matches the subject of the cached payload.

An additional concern is reflected or stored XSS via cache poisoning: if the cached response includes attacker-controlled data (e.g., from query parameters that are reflected without sanitization), subsequent users may execute scripts in their browser. When API keys are used for routing or logging but not properly isolated in the cache, the attack surface expands because an attacker might try to infer valid API keys or observe which keys result in cacheable responses, enabling more focused exploitation.

To mitigate cache poisoning when using API keys in Actix, ensure that cache keys are constructed from a strict, authorized subset of request attributes and that cached data never crosses tenant or user boundaries. Avoid including raw API key values directly in cache keys; instead, use a mapped identifier that the server resolves internally. This prevents key leakage in logs or cache stores and reduces the risk of key enumeration via cache side channels.

Below are concrete Actix examples that demonstrate secure handling of API keys with a focus on cache-safe patterns. The first example shows how to extract and validate an API key and derive a safe cache key without exposing the raw key.

use actix_web::{web, HttpRequest, HttpResponse, Responder};
use std::collections::HashMap;
use std::sync::Arc;

// Simulated cache store; in production, replace with a thread-safe cache (e.g., moka)
struct CacheStore(HashMap);

impl CacheStore {
    fn get(&self, key: &str) -> Option<&String> {
        self.0.get(key)
    }
    fn insert(&mut self, key: String, value: String) {
        self.0.insert(key, value);
    }
}

// A secure cache key builder that uses a normalized route + tenant identifier
fn build_cache_key(path: &str, tenant_id: &str) -> String {
    format!("cache:{}:{}", path, tenant_id)
}

async fn handle_request(
    req: HttpRequest,
    cache: web::Data>>,
) -> impl Responder {
    // 1) Extract API key from headers
    let api_key = match req.headers().get("X-API-Key") {
        Some(h) => h.to_str().unwrap_or(""),
        None => return HttpResponse::Unauthorized().body("Missing API key"),
    };

    // 2) Resolve tenant from key safely (pseudo-lookup)
    let tenant_id = match validate_api_key(api_key) {
        Ok(tid) => tid,
        Err(_) => return HttpResponse::Forbidden().body("Invalid API key"),
    };

    // 3) Build a cache key that does NOT include the raw API key
    let cache_key = build_cache_key(req.path(), &tenant_id);

    // 4) Serve from cache or compute and store safely
    let mut cache_guard = cache.lock().unwrap();
    if let Some(cached) = cache_guard.get(&cache_key) {
        return HttpResponse::Ok().body(cached.clone());
    }

    // Simulated computation; ensure response does not contain other clients’ data
    let response = format!("data_for:{}", tenant_id);
    cache_guard.insert(cache_key.clone(), response.clone());
    HttpResponse::Ok().body(response)
}

fn validate_api_key(key: &str) -> Result {
    // In practice, validate against a secure store; return tenant ID on success
    if key.len() == 32 { // simplistic example
        Ok("tenant_abc".to_string())
    } else {
        Err(())
    }
}

The second example shows how to enforce tenant isolation and avoid using the API key directly in cache logic by mapping it to an internal identifier before caching.

use actix_web::{web, HttpRequest, HttpResponse};
use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize)]
struct CachedItem {
    tenant: String,
    payload: String,
}

// A route that uses a service layer to abstract cache and key management
async fn get_tenant_data(
    req: HttpRequest,
    api_key: web::Header,
) -> HttpResponse {
    let key = api_key.into_inner();
    let tenant = match lookup_tenant_by_key(&key) {
        Some(t) => t,
        None => return HttpResponse::Unauthorized().finish(),
    };

    // Build a cache-safe key: path + tenant, never raw key
    let cache_key = format!("tenant_data:{}", tenant);

    // Assume cached response is validated to belong to tenant
    if let Some(cached) = DATA_CACHE.get(&cache_key) {
        return HttpResponse::Ok().json(cached);
    }

    // Produce tenant-specific response
    let item = CachedItem {
        tenant: tenant.clone(),
        payload: format!("secure_data_for_{}", tenant),
    };
    DATA_CACHE.insert(cache_key, item.clone());
    HttpResponse::Ok().json(item)
}

// Pseudo-lookup; replace with secure backend validation
fn lookup_tenant_by_key(key: &str) -> Option {
    if key.starts_with("valid_") {
        Some(key.trim_start_matches("valid_").to_string())
    } else {
        None
    }
}

// Simple in-memory cache for example; use a robust cache in production
static mut DATA_CACHE: Option> = None;

Key remediation practices:

• Never use raw API key values as part of cache keys; map them to tenant or user identifiers internally.
• Scope cached data by tenant or user ID and validate ownership on every cache retrieval.
• Avoid caching responses that contain secrets or PII unless cache eviction and isolation are rigorously enforced.
• Treat cache stores as shared memory: ensure that one client cannot retrieve another client’s cached entries through key confusion or injection.