Cache Poisoning in Flask with Api Keys

Cache poisoning in Flask occurs when an attacker causes a shared cache to store responses that are specific to one user or contain manipulated data, and those responses are later served to other users. When API keys are involved, the risk intensifies if responses are cached based on request headers without properly excluding sensitive or user-specific identifiers.

Consider a Flask endpoint that returns sensitive account information and uses an API key passed in a request header for authorization but does not exclude that header from cache key generation. A reverse proxy or application-level cache may treat requests with different API keys as distinct, yet if the response for one key is cached and later served to another caller, data exposure occurs. More critically, if the cache key is derived in part from the API key but the validation of authorization is performed after cache lookup, an attacker may be able to leverage a cached response to infer the presence or absence of certain resources without proper authorization checks—a form of BOLA/IDOR facilitated by caching behavior.

For example, if a cache key includes the API key header verbatim, multiple keys produce multiple cache entries, which may still be acceptable if each response is user-specific and short-lived. However, if the cache key omits the API key but the endpoint varies behavior based on the key, an attacker can make authenticated requests and then trick the cache into returning those responses to unauthenticated or low-privilege users. This violates the principle of proper authorization checks and can expose data that should be isolated per client or per key.

In practice, this can intersect with other findings such as excessive data exposure or missing input validation, especially if the cached response includes sensitive headers or cookies. Real-world cache poisoning chains may involve query parameters, cookies, and headers; when API keys are included in query strings or headers without normalization, they can inadvertently become part of the cache key, increasing storage of sensitive responses or enabling cross-user contamination.

To mitigate cache poisoning risks when using API keys in Flask, ensure that caching logic explicitly handles or excludes sensitive headers and that authorization is enforced before any cache lookup. Below are concrete, realistic code examples.

1. Exclude API keys from cache keys

Configure your caching layer to ignore the API key header when forming cache keys. This prevents different keys from creating separate cache entries for the same logical response when the underlying data and permissions are identical.

from flask import Flask, request, jsonify
from werkzeug.datastructures import CombinedMultiDict

app = Flask(__name__)

@app.before_request
def normalize_cache_key():
    # Remove sensitive headers so they do not affect cache key generation
    # This is a logical safeguard; actual cache implementation must ignore these.
    if 'X-API-Key' in request.headers:
        # In a real caching setup, you'd configure the cache to exclude this header.
        # Example conceptual step:
        # cache_key = generate_cache_key(path, method, exclude_headers=['X-API-Key'])
        pass

@app.route("/account")
def account():
    api_key = request.headers.get("X-API-Key")
    if not api_key:
        return jsonify({"error": "missing api key"}), 401
    # Perform authorization and data retrieval here
    return jsonify({"account": "data"})

2. Enforce authorization before cache lookup

Ensure that any cached response is only served after confirming the requester is authorized to access the specific resource. Do not rely on cache alone to enforce access control.

from flask import Flask, request, jsonify

app = Flask(__name__)

# Simulated cache dictionary
cache = {}

def get_cache_key(path, method, normalized_query):
    # Build a cache key that excludes sensitive headers
    return f"{method}:{path}:{normalized_query}"

def is_authorized(api_key, resource_id):
    # Replace with real authorization logic
    valid_keys = {"valid_key_user1": "user1", "valid_key_user2": "user2"}
    user = valid_keys.get(api_key)
    return user == resource_id

@app.route("/account/")
def account_detail(account_id):
    api_key = request.headers.get("X-API-Key")
    if not api_key:
        return jsonify({"error": "missing api key"}), 401
    if not is_authorized(api_key, account_id):
        return jsonify({"error": "forbidden"}), 403

    cache_key = get_cache_key(request.path, request.method, request.query_string.decode())
    cached = cache.get(cache_key)
    if cached is not None:
        return jsonify(cached)

    # Simulate data fetch
    data = {"account_id": account_id, "info": "sensitive data"}
    cache[cache_key] = data
    return jsonify(data)

3. Normalize and validate inputs

Treat API keys as opaque values and avoid using them directly in cache keys; instead, map them to normalized identifiers if needed for caching strategy. Always validate and sanitize inputs to reduce injection risks that may affect cache behavior.

# Example of using a normalized representation
import hashlib
def normalize_key(value):
    # Hash the key to avoid storing raw keys in logs or cache metadata
    return hashlib.sha256(value.encode()).hexdigest()

api_key = request.headers.get("X-API-Key")
if api_key:
    safe_key = normalize_key(api_key)
    # safe_key can be used for logging or non-sensitive cache metadata