Cache Poisoning in Fastapi with Cockroachdb

Cache poisoning in a FastAPI application that uses CockroachDB typically occurs when an attacker manipulates data that is subsequently cached and served to other users. Because CockroachDB is often used in distributed environments where read patterns are heavy, applications commonly cache query results to reduce latency. If the cache key does not incorporate user-specific or tenant-specific context, or if input used to build the cache key is not validated, one user can receive another user’s cached data.

Consider an endpoint that caches user profile information by user ID. If the ID is taken directly from user-supplied query parameters without strict validation, an attacker can change the parameter to view or overwrite cached entries belonging to others. Even when CockroachDB holds the source of truth, the cache layer becomes the vector: poisoned cache entries propagate incorrect or sensitive data until expiration or manual invalidation. This is particularly risky when combined with an incomplete understanding of how the application normalizes inputs before caching.

FastAPI’s dependency injection and caching integrations (for example, with Redis or in-memory caches) can inadvertently create these issues if developers do not rigorously scope cache keys and validate parameters. For example, concatenating a raw user-supplied string into a cache key without normalization or serialization safeguards can lead to key collisions or injection of malicious cache entries. Because CockroachDB is strongly consistent for reads within a transaction, an attacker may not need to exploit a database weakness directly; instead they exploit the cache’s trust in seemingly valid identifiers.

Compounding the risk, OpenAPI specifications generated by FastAPI may not explicitly document that identifiers are used as cache keys. This means runtime behavior diverges from generated docs, and scanners that compare spec definitions to observed behavior can flag Cache Poisoning as a finding when user-influenced data affects cached responses. The issue is not CockroachDB itself but how application code builds cache scope and validation around it.

To mitigate cache poisoning when using CockroachDB with FastAPI, enforce strict input validation, normalize identifiers, and scope cache keys with tenant or user context. Avoid using raw user input directly in cache keys or database queries. Below are concrete, secure patterns you can apply.

1. Validate and normalize identifiers before caching

Always validate identifiers against an allowlist or strict pattern, and normalize them (e.g., lowercasing and trimming) before using them in cache keys or queries. This prevents key manipulation and reduces risk of cache collisions.

from pydantic import BaseModel, validator
import re

class UserRequest(BaseModel):
    user_id: str

    @validator("user_id")
    def validate_user_id(cls, v):
        if not re.match(r"^[a-zA-Z0-9_-]{1,64}$", v):
            raise ValueError("Invalid user_id format")
        return v.strip().lower()

2. Scope cache keys with tenant or user context

Include a tenant or user context in the cache key to ensure isolation. Do not rely on global keys. Below is an example using a simple in-memory cache abstraction; adapt the pattern to your caching backend (Redis, Memcached, etc.).

from fastapi import Depends, FastAPI, HTTPException
from typing import Dict

app = FastAPI()

# Simple in-memory cache store; replace with your caching backend
cache: Dict[str, dict] = {}

def get_tenant_id() -> str:
    # In real apps, derive from auth context or subdomain
    return "tenant_abc"

def make_cache_key(base: str, user_id: str) -> str:
    tenant = get_tenant_id()
    return f"{tenant}:{base}:{user_id}"

@app.get("/users/{user_id}")
async def get_user(user_id: str, request: dict = Depends(lambda r: r)):
    safe_user_id = UserRequest(user_id=user_id).user_id
    key = make_cache_key("profile", safe_user_id)
    if key in cache:
        return cache[key]
    # Simulate a CockroachDB query; use parameterized queries in practice
    user_data = {"user_id": safe_user_id, "name": "Example"}
    cache[key] = user_data
    return user_data

3. Use CockroachDB with parameterized queries and avoid dynamic SQL

When interacting with CockroachDB, always use parameterized queries or an ORM that enforces placeholders. This prevents injection that could manipulate query results and subsequently cached data.

import asyncpg
from fastapi import Depends

async def get_user_from_db(user_id: str):
    conn: asyncpg.Connection = await asyncpg.connect("postgresql://user:pass@host/db")
    try:
        row = await conn.fetchrow(
            "SELECT user_id, name FROM users WHERE user_id = $1",
            user_id
        )
        return dict(row) if row else None
    finally:
        await conn.close()

4. Invalidate cache on writes and prefer short TTLs

When data changes, invalidate or update the affected cache entries. If full invalidation is costly, use shorter TTLs to limit the window of poisoned cache exposure. This is especially important in multi-tenant CockroachDB deployments where cross-tenant visibility is unacceptable.

# Pseudo-code for cache invalidation after a write
async def update_user_name(user_id: str, new_name: str):
    await write_to_cockroachdb(user_id, new_name)  # parameterized write
    safe_id = UserRequest(user_id=user_id).user_id
    key = make_cache_key("profile", safe_id)
    cache.pop(key, None)