Apollo Server: Browser bug allows for bypass of XS-Search (read-only Cross-Site Request Forgery) prevention
# Impact
In a Cross-Site Request Forgery attack, untrusted web content causes browsers to send authenticated requests to web servers which use cookies for authentication. While the web content is prevented from reading the request's response due to the Cross-Origin Request Sharing (CORS) protocol, an attacker may be able to cause side effects in the server ("CSRF" attack), or learn something about the response via timing analysis ("XS-Search" attack).
Apollo Server has a built-in feature which prevents CSRF and XS-Search attacks: it refuses to process GraphQL requests that could possibly have been sent by a spec-compliant web browser withou
## Impact
### What kind of vulnerability is it?
Apollo Server can log sensitive information (Studio API keys) if they are passed incorrectly (with leading/trailing whitespace) or if they have any characters that are invalid as part of a header value.
### Who is impacted?
Users who (all of the below):
* use either the schema reporting or usage reporting feature
* use an Apollo Studio API key which has invalid header values
* use the default fetcher (`node-fetch`) or configured their own `node-fetch` fetcher
The following node snippet can test whether your API key has invalid header values. This code is taken directly from `node-fetch@2`'s he
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 abili
apollo-server-core vulnerable to URL-based XSS attack affecting IE11 on default landing page
### Impact
The default landing page contained HTML to display a sample `curl` command which is made visible if the full landing page bundle could not be fetched from Apollo's CDN. The server's URL is directly interpolated into this command inside the browser from `window.location.href`. On some older browsers such as IE11, this value is not URI-encoded. On such browsers, opening a malicious URL pointing at an Apollo Router could cause execution of attacker-controlled JavaScript.
This only affects Apollo Server with the [default landing page](https://www.apollographql.com/docs/apollo-server/api/plugin/landing-pages/) enabled. Old browsers vi
Introspection in schema validation in Apollo Server
We encourage all users of Apollo Server to read this advisory in its entirety to understand the impact. The _Resolution_ section contains details on patched versions.
### Impact
If `subscriptions: false` is passed to the `ApolloServer` constructor options, there is no impact. If implementors were not expecting validation rules to be enforced on the WebSocket subscriptions transport **and** are unconcerned about introspection being enabled on the WebSocket subscriptions transport (or were not expecting that), then this advisory is not applicable. If `introspection: true` is passed to the `ApolloServer` constructor options, the impact is l