A shared cache can serve a response without asking the application to generate it again. That improves efficiency for public content. For customer-specific content, the cache must preserve the same access distinctions the application would enforce on a fresh request.
The review question is whether two requests that may receive different private data can be treated as equivalent by a caching layer. The answer depends on cache keys, response directives, and any custom rules configured between the user and the application.
Understand the directives actually in use
The HTTP caching standard distinguishes directives such as private, no-store, and no-cache. No-cache requires validation before reuse under the standard's rules; it does not simply mean that storage is prohibited. Private limits shared-cache storage, while no-store addresses storage by caches more broadly. RFC 9111 defines these semantics.
An illustrative account dashboard returns a customer's balance. The application may set an appropriate directive, but a custom CDN rule can alter the intended behavior. Review the response as delivered through the actual edge configuration, not only from the origin server.
Map what makes a response different
Identify the request properties that affect the response: authenticated user, tenant, role, language, query parameters, and selected resource. Not every difference belongs in a cache key; some responses should bypass shared caching entirely. The design needs to match the content's access policy.
Include error responses and redirects. A cached redirect containing a customer-specific destination or a cached error containing private context can disclose information even when the main success response is handled correctly.
Test with separate browser contexts
Create two synthetic customers with distinct visible markers. Request a protected page as the first customer, then request the equivalent URL as the second customer and as an unauthenticated client. Repeat through the same deployment path to exercise the configured cache.
Inspect response bodies, headers, and cache indicators. A cache hit is not inherently a finding; the question is whether the returned content and access behavior are correct for the requester. Record the sequence so a developer can reproduce any cross-account response.
Include permission changes and invalidation
Revoke access to a synthetic document after it has been viewed and repeat the request. Determine whether the intended policy requires immediate denial and how caches are invalidated or bypassed to achieve it. Browser-local copies and shared-cache copies can have different behavior.
The assessment can identify which responses are cached, which request distinctions are preserved, and what happens after access changes. This evidence supports a specific remediation, such as removing a broad cache rule or correcting response handling. It avoids equating the mere presence of a CDN with either a security failure or a security guarantee.
Sources
OWASP: Web Cache Security. The dashboard and marker-based test are illustrative.
