A response sets a session-like cookie and allows shared caching
A fetched response set a session-like cookie while its Cache-Control directives allowed a shared cache to store the response.
Why it matters
If a shared cache stores a personalized response, another visitor could receive content intended for someone else. The actual outcome depends on cache behavior and the response path.
How ShipReady detects it
What it inspects
ShipReady reads Set-Cookie and Cache-Control headers from each fetched page response. It identifies session-like cookies by name and evaluates directives that permit shared caching.
What triggers a finding
The rule triggers when a response sets a cookie that matches the session-name heuristic and its Cache-Control header permits shared caching under the check's directive rules.
What the evidence shows
The scanned response combined the observed cookie header and cache-control policy that the rule treats as cacheable by a shared cache.
Limits of this check
The scanner does not operate a CDN or proxy, observe a cache hit, prove that a cookie authenticates a user, or inspect responses outside the crawl. A finding indicates a risky header combination, not confirmed cross-user session disclosure.
How to fix it
Keep session-setting responses out of shared caches
Set an appropriate private or no-store cache policy for responses that establish or change a user session. Keep public caching only for responses that are genuinely identical for every visitor.
Review cache-layer rules
Check CDN, reverse-proxy, and framework caching rules for overrides that can cache personalized routes.
How to verify the change
Inspect the deployed response headers
Request the affected route as an unauthenticated and authenticated user, then review cache behavior in the deployed environment.
Expected: Session-setting responses are not eligible for shared caching and cache rules do not override that policy.