Batched HTTP requests may set incorrect `cache-control` response header

Impact

In Apollo Server 3 and 4, the cache-control HTTP response header may not reflect the cache policy that should apply to an HTTP request when that HTTP request contains multiple operations using HTTP batching. This could lead to data being inappropriately cached and shared.

Apollo Server allows clients to send multiple operations in a single HTTP request. The results of these operations are returned in a single HTTP response, with a single set of headers. Apollo Client Web and Apollo Kotlin both have opt-in features to use batched requests.

Apollo Server has several features relating to caching. This advisory is about the ability to set the cache-control response header based on field- and operation-specific cache hints. (It is not about the "response cache plugin".) This header can be interpreted by a reverse proxy such as a CDN in front of your server, or by a browser.

In Apollo Server 2, plugins such as the cache control plugin could not control the HTTP headers of responses to batch requests. This meant that batch requests never got the cache-control response header.

In Apollo Server 3 and 4, plugins can set HTTP response headers. But for batched requests, plugins essentially assemble a separate set of response headers in parallel for each operation, and then the header sets are merged together. If plugins set the same header on multiple operations, one value is chosen arbitrarily.

This meant that if a client sent a batched HTTP request with two operations with different cache policies, Apollo Server 3 and 4 would return a cache-control header that only applies to one of the operations. If one operation is allowed to be cached and the other operation is not allowed to be cached, the full response including both results could still end up being cached in a CDN or other reverse proxy cache.

Note that valid batched requests must be POST requests. (There's no defined format for sending batched requests over GET.) So in order for this incorrect cache-control header to have a harmful effect, a cache must allow caching POST requests. This means this bug is unlikely to cause incorrect caching in browser or mobile client caches, or in many reverse proxy/CDN caches.

This issue could lead to cache poisoning attacks. For example, if a client app regularly sends an operation that should not be cached due to its dependency on session-specific information in the same HTTP request as an operation that can be cached in a shared cache, an attacker could send its own version of the request to the server and manage to get the response to its request stored in the shared cache; other users would then see the response specific to the attacker for the first operation rather than the response for their own session. That said, we expect that in a system where this cache poisoning attack is feasible, normal operation would also run into the issue and users may have already disabled one of the features in order for their system to function properly.