Cache Poisoning in Fastapi with Api Keys

Cache poisoning occurs when an attacker causes a cache to store malicious or incorrect responses that are later served to other users. In Fastapi applications that rely on API keys for access control, misconfigurations can cause responses that should be private or personalized to be cached and shared across users.

When API keys are used only as request headers and not considered as part of the cache key, a cache layer (such as an HTTP proxy or CDN) may treat requests with different keys as equivalent if the method, path, and query parameters are identical. This means a response generated for one API consumer can be reused for another, potentially exposing data that should be isolated. For example, a user-specific detail like /users/me/profile could be cached after the first authenticated request and then served to a different user, bypassing intended access boundaries.

Additionally, unsafe usage of query parameters that reflect user or tenant identifiers without canonicalization can lead to cache fragmentation or injection. If an API key is accepted both as a header and as a query parameter, and only one of them is used for routing while the other influences response content, the cache may inconsistently index responses. Attackers might probe endpoints that include keys in query strings to discover whether distinct keys produce different cache entries, enabling them to retrieve another tenant’s data through a cached response.

Another scenario involves mutable HTTP headers that influence response content but are omitted from cache normalization rules. For instance, a custom header like X-Tenant-ID may determine database routing, yet the caching policy ignores it. An attacker who can cause the application to cache a response with a poisoned or controlled header value can subsequently trigger that cached entry for other clients, leading to data leakage or incorrect behavior.

These issues are detectable by scanners that compare authenticated and unauthenticated attack surfaces, correlate spec definitions with runtime behavior, and test header and query-parameter handling. Proper cache design, combined with disciplined API key usage, reduces the likelihood that sensitive or user-specific responses are stored and shared inadvertently.

To mitigate cache poisoning risks when using API keys in Fastapi, ensure that caching mechanisms treat keys as part of the cache key and avoid exposing sensitive operations through query parameters.

Example 1: API key in header, excluded from query-based caching

Configure your caching layer to incorporate the API key header so that responses are segregated per consumer. Below is a Fastapi-compatible pattern using explicit route dependencies and response caching that respects the X-API-Key header:

from fastapi import Fastapi, Depends, Header, HTTPException
from fastapi.responses import JSONResponse
import hashlib

app = Fastapi()

# Simulated key store
VALID_KEYS = {"tenant_alpha": "abc123", "tenant_beta": "def456"}

def get_api_key(x_api_key: str = Header(...)):
    if x_api_key not in VALID_KEYS.values():
        raise HTTPException(status_code=401, detail="Invalid API key")
    # Map key to tenant for downstream use
    for tenant, key in VALID_KEYS.items():
        if key == x_api_key:
            return tenant
    raise HTTPException(status_code=401, detail="Unauthorized")

@app.get("/data")
async def get_data(tenant: str = Depends(get_api_key)):
    # In a real app, this would query a tenant-isolated data source
    payload = {"tenant": tenant, "message": "secure data"}
    return JSONResponse(content=payload)

This approach ensures that authorization is validated on each request and that caching can be configured to include the tenant identifier derived from the key, preventing cross-tenant cache reuse.

Example 2: Avoid using API keys in query parameters for cache-sensitive operations

Prefer headers over query parameters for keys. If query usage is unavoidable, canonicalize and include them in cache normalization. Here is an example of rejecting requests that misuse keys in the query string:

from fastapi import Fastapi, Query, Security
from fastapi.security import APIKeyHeader

app = Fastapi()
api_key_header = APIKeyHeader(name="X-API-Key")

async def verify_key(key: str = Security(api_key_header)):
    if key != "expected_key":
        raise HTTPException(status_code=403, detail="Forbidden")
    return key

@app.get("/items")
async def list_items(key: str = Security(verify_key)):
    # Respond without exposing key-derived data in query
    return {"items": ["a", "b"]}

By enforcing header-only usage and avoiding reflection of keys in query parameters, you reduce the risk that caching layers inadvertently index responses by key and enable poisoning across users.

Finally, document cache rules that explicitly incorporate tenant or consumer identifiers derived from API keys, and validate that your infrastructure does not store responses containing sensitive or user-specific payloads in shared caches. Regular testing with security tools that perform unauthenticated and authenticated scans helps identify inconsistencies between intended and actual cache behavior.