Cache Poisoning in Actix with Jwt Tokens

Cache poisoning occurs when an attacker tricks a caching layer into storing malicious content that is later served to other users. In Actix-based APIs that rely on JWT tokens for authorization, this risk arises when responses are cached based only on public or partially trusted request attributes while the authorization data in JWT tokens is either ignored or improperly validated before caching.

Consider an endpoint that returns user-specific data and uses JWT tokens to identify the subject and roles. If the caching logic uses only the request path and query parameters, two different users with different JWT tokens could receive the same cached response. One user might receive another user’s profile, or an attacker could inject a malicious payload into a response that gets cached and subsequently served to other users. This can lead to horizontal privilege escalation, exposure of private data, or the propagation of malicious content through the application.

When JWT tokens are accepted without strict validation—such as verifying the signature, issuer, audience, and expiration—an attacker might supply a malformed or unsigned token that still passes superficial checks. Actix middleware that parses JWT tokens but does not enforce strict validation may inadvertently allow crafted requests to influence cache keys or bypass intended scoping. If the cache key does not incorporate the validated subject or a hash of the token’s claims, the boundary between users blurs, enabling cache poisoning.

Real-world attack patterns mirror known issues in token handling and cache segregation. For example, an attacker may attempt IDOR-like behavior by modifying a JWT’s subject claim to reference another user’s resource, then observe whether cached responses reveal information across users. In systems that do not incorporate authorization context into caching decisions, this becomes feasible. Similarly, if responses include sensitive headers or cookies that are not stripped before caching, sensitive data can persist in the cache and be disclosed to unauthorized clients.

To mitigate these risks, treat JWT tokens as authoritative identity inputs and ensure that validated claims are part of the cache key. Do not cache responses where authorization is required unless you can guarantee that cached content cannot be shared across users or scopes. Apply strict token validation and scope checks before any processing that might influence what is cached, and avoid caching responses that contain user-specific or sensitive data unless absolutely necessary and properly segregated.

Remediation centers on strict JWT validation and ensuring that authorization context is part of cache decisions. In Actix, validate the token before using any claims to derive caching behavior. Below is an example of configuring an Actix extractor that validates JWTs using the jsonwebtoken crate and produces a validated claims struct for downstream handlers.

use actix_web::{dev::ServiceRequest, Error, HttpResponse};
use actix_web_httpauth::extractors::bearer::BearerAuth;
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    roles: Vec,
    exp: usize,
    iss: String,
    aud: String,
}

async fn validate_jwt(auth: BearerAuth) -> Result<Claims, HttpResponse> {
    let token = auth.token();
    let validation = Validation::new(Algorithm::HS256);
    let token_data = decode::<Claims>(
        token,
        &DecodingKey::from_secret("your_secret".as_ref()),
        &validation,
    ).map_err(|_| HttpResponse::Unauthorized().finish())?;
    // Enforce audience and issuer checks
    if token_data.claims.iss != "trusted-issuer" || token_data.claims.aud != "my-api-audience" {
        return Err(HttpResponse::Unauthorized().finish());
    }
    Ok(token_data.claims)
}

// In your Actix App factory, wrap routes with a guard that uses `validate_jwt`
// to ensure only requests with valid tokens proceed.

With validated claims in hand, incorporate the subject and roles into your cache key to ensure proper segregation. For example, if you use a custom caching layer, build a composite key that includes the validated sub and a hash of relevant claims. This prevents responses intended for one user from being served to another, even if the request path and query parameters are identical.

Additionally, enforce scope and role checks at the handler level before returning data that might be cached. Do not rely on caching to enforce authorization. If an endpoint must be cached, ensure that the cache key includes sufficient authorization context and that responses containing sensitive information are never cached for shared or long-lived caches.

For automated checks of these patterns, middleBook can scan your Actix endpoints and surface misconfigurations where JWT handling and caching intersect. Using the CLI, run middlebrick scan <url> to detect potential cache poisoning risks tied to token validation and caching logic. Teams on the Pro plan can enable continuous monitoring so that changes to authentication or caching behavior trigger reviews before deployment, and the GitHub Action can fail builds if risk thresholds are exceeded.