Cache Poisoning in Spring Boot with Firestore

Cache poisoning in the context of a Spring Boot application that reads from and writes to Google Cloud Firestore occurs when untrusted or unvalidated data causes the cache to store incorrect, misleading, or sensitive responses. This typically happens when the application caches keyed data where the key can be influenced by an attacker, allowing them to overwrite entries or cause the application to retrieve malicious or incorrect values on subsequent requests.

In Spring Boot, caching is commonly implemented with annotations such as @Cacheable, @CachePut, and @CacheEvict. When the cache key is derived from user-controlled input, such as an API parameter that maps to a Firestore document ID or query parameter, an attacker may supply crafted input that modifies the cache key in a predictable way. For example, if the key is built from a request parameter without proper normalization or strict validation, two distinct logical requests might map to the same cache key, causing a collision.

Firestore is often used as the backend data store in such architectures, providing structured documents accessed via paths and document IDs. If a Spring Boot service uses Firestore document IDs directly from user input to populate cache keys, an attacker can force cache collisions or deliberately overwrite legitimate entries. Consider a scenario where a document ID is derived from an unvalidated query parameter; a malicious actor can cause the application to store falsified responses under a legitimate key, leading to other users receiving poisoned data.

Additionally, caching behavior can inadvertently expose sensitive Firestore data if cache entries are shared across users or tenants. If tenant identifiers or user IDs are not part of the cache key, one user may retrieve another user's Firestore-backed data from the cache. This misconfiguration is especially risky when combined with Firestore’s flexible security rules, where rules that are permissive at the document level may not account for cached data exposure in the application layer.

Another vector involves query result caching. If a Spring Boot service caches the results of a Firestore query that includes user-supplied filters, an attacker may manipulate these filters to poison the cached result set. Subsequent users who perform similar queries may receive the tainted data, believing it to be authoritative. Because Firestore queries can return large datasets, the impact of such poisoning can be widespread and persistent across cache TTLs.

These risks are not inherent to Firestore or Spring Boot but arise from insecure caching design patterns. Proper cache key design, strict input validation, and tenant-aware caching strategies are essential to prevent cache poisoning in this specific technology stack.

To mitigate cache poisoning when using Firestore with Spring Boot, you must ensure that cache keys are deterministic, scoped, and derived from trusted, normalized data. Avoid using raw user input as cache keys or parts of keys without validation and contextual isolation.

First, design cache keys that incorporate tenant or user context to prevent cross-user contamination. For example, include a validated tenant identifier and a normalized resource type prefix in the key. Use Spring’s CacheKeyGenerator to enforce consistent key generation across methods.

@Cacheable(cacheNames = "userProfiles", key = "#tenantId + ':' + #userId + ':' + #root.methodName")
public UserProfile getProfile(String tenantId, String userId) {
    DocumentReference docRef = firestore.collection("tenants")
        .document(tenantId)
        .collection("profiles")
        .document(userId);
    DocumentSnapshot snapshot = docRef.get().get();
    return snapshot.toObject(UserProfile.class);
}

Second, avoid using Firestore document IDs directly from user input. Instead, map user input to document IDs via server-side lookups using immutable, server-generated identifiers. If you must use IDs from clients, validate them against a whitelist or pattern to ensure they conform to expected formats.

public String resolveProfileId(String tenantId, String rawProfileRef) {
    // Validate tenantId format
    if (!tenantId.matches("^[a-zA-Z0-9-]{1,30}$")) {
        throw new IllegalArgumentException("Invalid tenantId");
    }
    // Ensure the rawProfileRef belongs to the tenant and follows a safe path
    DocumentReference safeRef = firestore.collection("tenants")
        .document(tenantId)
        .collection("profiles")
        .document(rawProfileRef);
    // Confirm existence and ownership before using the document ID in cache keys
    ApiFuture future = safeRef.get();
    if (future.get().exists()) {
        return rawProfileRef;
    }
    throw new NotFoundException("Profile not found or access denied");
}

Third, scope query caches by including query parameters in the cache key. This prevents different filter combinations from overwriting each other’s cached results.

@Cacheable(cacheNames = "searchResults", key = "#tenantId + ':' + #category + ':' + #filters.hashCode()")
public List searchProducts(String tenantId, String category, Map filters) {
    CollectionReference products = firestore.collection("tenants")
        .document(tenantId)
        .collection("categories")
        .document(category)
        .collection("products");
    Query query = buildQueryFromFilters(products, filters);
    QuerySnapshot snapshot = query.get().get();
    return snapshot.toObjects(Product.class);
}

Fourth, set appropriate TTLs and consider active eviction strategies for sensitive data. Short TTLs reduce the window for poisoned cache entries, but they must be balanced with performance needs.

Finally, audit your Firestore security rules to ensure they align with your caching model. Rules that permit broad read access can amplify the impact of cache poisoning if combined with overly permissive cache scopes. Combine least-privilege rules with tenant-aware cache keys to reduce risk.