How CloudFront Request Collapsing Can Expose Users’ Data—and How to Prevent It
Summary
Request collapsing can send one user’s sensitive response to other users despite Cache-Control: no-cache. The article explains the risk in CloudFront and recommends cache settings and simultaneous-request testing to reduce exposure.
Key points
- Request collapsing occurs when a cache groups simultaneous requests with the same cache key and returns the first response to all requestors.
- In CloudFront, delayed requests can receive a response even when the origin marks it Cache-Control: no-cache, potentially exposing one user’s data to another.
- The article records 14 incidents matching web-cache problem symptoms; 11 occurred in the past four years. The author notes many reports could not be independently verified.
- Two incidents specifically identified unexpected request collapsing as the root cause, according to the article.
- For CloudFront requests that should not be cached, use the managed CachingDisabled policy, or set the minimum TTL to 0 and have the origin send Cache-Control: no-cache; the article says both settings are required for the latter option.
- Test cache behavior with simultaneous requests from different users, not only sequential tests, and review cache policies when API paths or application behavior change.
Article Details
- Defense Focus
- Prevent sensitive user-specific responses from being shared across users through web caching and request collapsing.
- Detection Methods
- Test cache behavior using multiple users and verify that user-specific responses are never returned to another user.
- Run simultaneous requests for the same cache key, in addition to sequential tests, to expose request-collapsing behavior.
- Review cache-key patterns and cache policies whenever application API paths change.
- Data Sources
- Cache policy and cache-key configuration
- Origin response Cache-Control headers
- Responses to sequential and simultaneous requests from multiple users
- Platforms
- Amazon CloudFront
- Defensive Actions
- For CloudFront paths that must not be cached, use the managed CachingDisabled policy.
- Alternatively, set the cache behavior minimum TTL to 0 and configure the origin to send Cache-Control: no-cache for each object that must not be cached; the article says both are required.
- Test with simultaneous requests from different users, not only sequential requests.
- Reassess cache policies when API paths change, since path-pattern exclusions may no longer cover the updated routes.