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 limited to user-provided validation rules (i.e., using validationRules) since there would be no expectation that introspection was disabled.
The enforcement of user-provided validation rules on the HTTP transport is working as intended and is unaffected by this advisory. Similarly, disabling introspection on the HTTP transport is working as intended and is unaffected by this advisory.
Note: Unless subscriptions: false is explicitly passed to the constructor parameters of new ApolloServer({ ... }), subscriptions are enabled by default, whether or not there is a Subscription type present in the schema. As an alternative to upgrading to a patched version, see the Workarounds section below to disable subscriptions if it is not necessary.
In cases where subscriptions: false is not explicitly set, the subscription server is impacted since validation rules which are enforced on the main request pipeline within Apollo Server were not being passed to the SubscriptionServer.create invocation (seen here, prior to the patch).
The omitted validation rules for the subscription server include any validationRules passed by implementors to the ApolloServer constructor which were expected to be enforced on the subscriptions WebSocket endpoint. Additionally, because an internal NoIntrospection validation rule is used to disable introspection, it would have been possible to introspect a server on the WebSocket endpoint that the SubscriptionServer creates even though it was not possible on other transports (e.g. HTTP).
The severity of risk depends on whether sensitive information is being stored in the schema itself. The contents of schema descriptions, or secrets which might be revealed by the names of types or field names within those types, will determine the risk to individual implementors.
Affected packages
The bug existed in apollo-server-core versions prior to version 2.14.2, however, this means all integration packages (e.g., apollo-server-express, etc.) prior to version 2.14.2 which depend on apollo-server-core for their subscriptions support are affected. This includes the apollo-server package that automatically provides an Express server.
Therefore, for officially published Apollo Server packages, the full list of affected packages includes: apollo-server, apollo-server-azure-functions, apollo-server-cache-memcached, apollo-server-core, apollo-server-cloud-functions, apollo-server-cloudflare, apollo-server-express, apollo-server-fastify, apollo-server-hapi, apollo-server-koa, apollo-server-lambda, and apollo-server-micro.
Note: The full list included here doesn't fit into the box provided by the GitHub Security Advisories form.
Resolution
The problem is resolved in Apollo Server versions 2.14.2 or higher. If upgrading is not an option, see Workarounds below. When upgrading, ensure that the affected integration package (e.g., apollo-server-express) and the apollo-server-core package are both updated to the patched versions. (The version numbers should both be 2.14.2.)
Workarounds
Upgrading to a patched version is the recommended solution. If upgrading is not an option, subscriptions can be disabled with subscriptions: false to resolve the impact. Disabling subscriptions in this way will disable all subscriptions support and the WebSocket transport:
const server = new ApolloServer({
subscriptions: false,
/* Other options, such as typeDefs, resolvers, schema, etc. */
});
For more information
If you have any questions or comments about this advisory, please open an issue and the maintainers will try to assist.
Credit and appreciation
Apollo fully believes in ethical disclosure of vulnerabilities by security researchers who notify us with details and provide us time to address and fix the issues before publicly disclosing.
Credit for this discovery goes to the team at Bitwala, who reported the concern to us responsibly after discovering it during their own auditing.
In certain configurations, Apollo Server serves the client-side web app "GraphQL Playground" from the same web server that executes GraphQL operations. This web app has access to cookies and other credentials associated with the web server's operations. There is a cross-site scripting vulnerability in GraphQL Playground that allows for arbitrary JavaScript code execution in your web server's origin. If a user clicks a specially crafted link to your GraphQL Playground page served by Apollo Server, an attacker can steal cookies and other private browser data.
Details of the underlying GraphQL Playground vulnerability are available in this graphql-playground advisory. (A similar vulnerability exists in the related graphiql project.) This advisory focuses on identifying whether Apollo Server installations are vulnerable and mitigating the vulnerability in Apollo Server; see the other advisories for details on the XSS vulnerability itself.
The impact of this vulnerability is more severe if (as is common) your GraphQL server's origin URL is an origin that is used to store sensitive data such as cookies.
In order for this vulnerability to affect your Apollo Server installation, it must actually serve GraphQL Playground. The integration between Apollo Server and GraphQL Playground is different in Apollo Server 2 and Apollo Server 3. You can tell which version of Apollo Server you are running by looking at the version of the package from which you import the ApolloServer class: this may be apollo-server, apollo-server-express, apollo-server-lambda, etc.
Apollo Server 3
Apollo Server 3 does not serve GraphQL Playground by default. It has a landing page plugin system and the default plugin is a simple splash page that is not vulnerable to this exploit, linking to Apollo Sandbox Explorer. (We chose to change the default because GraphQL Playground is not actively maintained.)
If you are running Apollo Server 3, then you are only vulnerable if you explicitly import the ApolloServerPluginLandingPageGraphQLPlayground plugin and pass it to your ApolloServer's constructor in the plugins array. Otherwise, this advisory does not apply to your server.
Apollo Server 2
Apollo Server 2 serves GraphQL Playground by default, unless the NODE_ENV environment variable is set to production, or if you explicitly configure it via the playground option to the ApolloServer constructor.
Your Apollo Server 2 installation is vulnerable if any of the following is true:
You pass playground: true to the ApolloServer constructor
You pass some other object like playground: {title: "Title"} to the ApolloServer constructor
You do not pass any playground option to the ApolloServer constructor, and the NODE_ENV environment variable is not set to production
Apollo Server 1
Apollo Server 1 included graphiql instead of graphql-playground. graphiql isn't automatically enabled in Apollo Server 1: you have to explicitly call a function such as graphiqlExpress to enable it. Because Apollo Server 1 is not commonly used, we have not done a detailed examination of whether the integration between Apollo Server 1 and graphiql is vulnerable to a similar exploit. If you are still using Apollo Server 1, we recommend you disable graphiql by removing the graphiqlExpress call, and then upgrade to a newer version of Apollo Server.
Patches and workarounds
There are several approaches you can take to ensure that your server is not vulnerable to this issue.
Upgrade Apollo Server
The vulnerability has been patched in Apollo Server 2.25.3 and Apollo Server 3.4.1. To get the patch, upgrade your Apollo Server entry point package to one of the fixed versions; this package may be apollo-server, apollo-server-express, apollo-server-lambda, etc. Additionally, if you depend directly on apollo-server-core in your package.json, make sure that you upgrade it to the same version.
Upgrade Playground version only
If upgrading to the latest version of Apollo Server 2 or 3 quickly will be challenging, you can configure your current version of Apollo Server to serve the latest version of the GraphQL Playground app. This will pin your app to serve a specific version of GraphQL Playground and you will not receive updates to it when you upgrade Apollo Server later, but this may be acceptable because GraphQL Playground is not actively maintained.
The way to do this depends on what version of Apollo Server you're using and if you're already configuring GraphQL Playground.
Apollo Server 3: If you are using Apollo Server 3, then you are only vulnerable if your serve explicitly calls ApolloServerPluginLandingPageGraphQLPlayground and passes it to the Apollo Server constructor in the plugins array. Add the option version: '1.7.42' to this call, so it looks like:
Apollo Server 2 with no explicit playground option: If you are using Apollo Server 2 and do not currently pass the playground option to new ApolloServer, add a playground option like so:
Apollo Server 2 with playground: true or playground: {x, y, z}: If you are using Apollo Server 2 and currently pass true or an object to new ApolloServer, pass the version option under the playground option like so:
new ApolloServer({ playground: { version: '1.7.42', x, y, z } })
Disable GraphQL Playground
If upgrading Apollo Server or GraphQL Playground is challenging, you can also disable GraphQL Playground.
In Apollo Server 3, remove the call to ApolloServerPluginLandingPageGraphQLPlayground from your ApolloServer constructor's plugins array. This will replace GraphQL Playground with a simple splash page. See the landing page plugins docs for details.
In Apollo Server 2, add playground: false to your ApolloServer constructor: new ApolloServer({ playground: false }). This will replace GraphQL Playground with an attempt to execute a GraphQL operation, which will likely display an error in the browser.
The graphql-upload npm package can execute GraphQL operations contained in content-type: multipart/form-data POST requests. Because they are POST requests, they can contain GraphQL mutations. Because they use content-type: multipart/form-data, they can be "simple requests" which are not preflighted by browsers.
If your GraphQL server uses graphql-upload and uses SameSite=None cookies for authentication, then JS on any origin can cause browsers to send cookie-authenticated mutations to your GraphQL server, which will be executed without checking your CORS policy first. (The attack won't be able to see the response to the mutation if your CORS policy is set up properly, but the side effects of the mutation will still happen.)
Additionally, if your GraphQL server uses graphql-upload and relies on network properties for security (whether by explicitly looking at the client's IP address or by only being available on a private network), then JS on any origin can cause browsers (which may be on a private network or have an allowed IP address) to send mutations to your GraphQL server, which will be executed without checking your CORS policy first. (This attack does not require your server to use cookies. It is in some cases prevented by some browsers such as Chrome.)
Apollo Server 2 bundled graphql-upload and enabled it by default, so by default, Apollo Server 2 servers are vulnerable to these CSRF attacks. (Apollo Server 1 did not bundle graphql-upload. Apollo Server 3 no longer bundles graphql-upload, although AS3's docs do document how to manually integrate with graphql-upload.) It is enabled even if your server makes no use of the upload functionality.
If you are running Apollo Server 2 (older than v2.25.4) and do not specify uploads: false to new ApolloServer, then you are vulnerable to this CSRF mutation attack.
We recently introduced an opt-in CSRF prevention feature in Apollo Server 3.7. This feature successfully protects against CSRF even if you have manually integrated your AS3.7 server with graphql-upload. However, this feature is not available for Apollo Server 2.
Patches
If you are using Apollo Server 2 and do not actually use uploads in your schema (ie, the Upload scalar is not used as the argument to any field or in any input object definition, and you do not specify uploads to new ApolloServer), then upgrading to Apollo Server 2.25.4 will automatically disable graphql-upload in your server. This will fix the CSRF mutation vulnerability.
Upgrading to v2.25.4 does still leave your server vulnerable to non-mutation CSRF attacks such as timing attacks against query operations. To protect yourself against these potentially lower impact CSRF attack, we encourage upgrading to Apollo Server v3.7 and enabling CSRF prevention. See the Apollo Server 3 migration guide and the CSRF prevention docs for details.
If you are actively using the uploads feature with Apollo Server 2, then upgrading to v2.25.4 will not disable the feature and you will still be vulnerable. You should instead upgrade to v3.7 and enable the CSRF prevention feature.
If you are manually integrating the graphql-upload package with any version of Apollo Server (or any Node GraphQL server) and need to continue using the feature, then you must enable some sort of CSRF prevention feature to fix this vulnerability. We recommend the CSRF prevention feature in Apollo Server 3.7.
Workarounds
Instead of upgrading your Apollo Server 2 server, you can specify uploads: false to new ApolloServer to disable the graphql-upload integration and protect against CSRF mutations. (Only do this if you do not actually use the uploads feature in your server!) This will still leave your server vulnerable to non-mutation CSRF attacks such as timing attacks against query operations; you need to upgrade to v3.7 and enable CSRF prevention to protect against these attacks.
This PR contains the following updates:
2.9.3
->2.25.3
GitHub Vulnerability Alerts
GHSA-w42g-7vfc-xf37
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 theApolloServer
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. Ifintrospection: true
is passed to theApolloServer
constructor options, the impact is limited to user-provided validation rules (i.e., usingvalidationRules
) since there would be no expectation that introspection was disabled.The enforcement of user-provided validation rules on the HTTP transport is working as intended and is unaffected by this advisory. Similarly, disabling introspection on the HTTP transport is working as intended and is unaffected by this advisory.
In cases where
subscriptions: false
is not explicitly set, the subscription server is impacted since validation rules which are enforced on the main request pipeline within Apollo Server were not being passed to theSubscriptionServer.create
invocation (seen here, prior to the patch).The omitted validation rules for the subscription server include any
validationRules
passed by implementors to theApolloServer
constructor which were expected to be enforced on the subscriptions WebSocket endpoint. Additionally, because an internalNoIntrospection
validation rule is used to disable introspection, it would have been possible to introspect a server on the WebSocket endpoint that theSubscriptionServer
creates even though it was not possible on other transports (e.g. HTTP).The severity of risk depends on whether sensitive information is being stored in the schema itself. The contents of schema descriptions, or secrets which might be revealed by the names of types or field names within those types, will determine the risk to individual implementors.
Affected packages
The bug existed in
apollo-server-core
versions prior to version 2.14.2, however, this means all integration packages (e.g.,apollo-server-express
, etc.) prior to version 2.14.2 which depend onapollo-server-core
for their subscriptions support are affected. This includes theapollo-server
package that automatically provides an Express server.Therefore, for officially published Apollo Server packages, the full list of affected packages includes:
apollo-server
,apollo-server-azure-functions
,apollo-server-cache-memcached
,apollo-server-core
,apollo-server-cloud-functions
,apollo-server-cloudflare
,apollo-server-express
,apollo-server-fastify
,apollo-server-hapi
,apollo-server-koa
,apollo-server-lambda
, andapollo-server-micro
.Resolution
The problem is resolved in Apollo Server versions 2.14.2 or higher. If upgrading is not an option, see Workarounds below. When upgrading, ensure that the affected integration package (e.g.,
apollo-server-express
) and theapollo-server-core
package are both updated to the patched versions. (The version numbers should both be 2.14.2.)Workarounds
Upgrading to a patched version is the recommended solution. If upgrading is not an option, subscriptions can be disabled with
subscriptions: false
to resolve the impact. Disabling subscriptions in this way will disable all subscriptions support and the WebSocket transport:For more information
If you have any questions or comments about this advisory, please open an issue and the maintainers will try to assist.
Credit and appreciation
Apollo fully believes in ethical disclosure of vulnerabilities by security researchers who notify us with details and provide us time to address and fix the issues before publicly disclosing.
Credit for this discovery goes to the team at Bitwala, who reported the concern to us responsibly after discovering it during their own auditing.
GHSA-qm7x-rc44-rrqw
Impact
In certain configurations, Apollo Server serves the client-side web app "GraphQL Playground" from the same web server that executes GraphQL operations. This web app has access to cookies and other credentials associated with the web server's operations. There is a cross-site scripting vulnerability in GraphQL Playground that allows for arbitrary JavaScript code execution in your web server's origin. If a user clicks a specially crafted link to your GraphQL Playground page served by Apollo Server, an attacker can steal cookies and other private browser data.
Details of the underlying GraphQL Playground vulnerability are available in this
graphql-playground
advisory. (A similar vulnerability exists in the relatedgraphiql
project.) This advisory focuses on identifying whether Apollo Server installations are vulnerable and mitigating the vulnerability in Apollo Server; see the other advisories for details on the XSS vulnerability itself.The impact of this vulnerability is more severe if (as is common) your GraphQL server's origin URL is an origin that is used to store sensitive data such as cookies.
In order for this vulnerability to affect your Apollo Server installation, it must actually serve GraphQL Playground. The integration between Apollo Server and GraphQL Playground is different in Apollo Server 2 and Apollo Server 3. You can tell which version of Apollo Server you are running by looking at the version of the package from which you import the
ApolloServer
class: this may beapollo-server
,apollo-server-express
,apollo-server-lambda
, etc.Apollo Server 3
Apollo Server 3 does not serve GraphQL Playground by default. It has a landing page plugin system and the default plugin is a simple splash page that is not vulnerable to this exploit, linking to Apollo Sandbox Explorer. (We chose to change the default because GraphQL Playground is not actively maintained.)
If you are running Apollo Server 3, then you are only vulnerable if you explicitly import the
ApolloServerPluginLandingPageGraphQLPlayground
plugin and pass it to yourApolloServer
's constructor in theplugins
array. Otherwise, this advisory does not apply to your server.Apollo Server 2
Apollo Server 2 serves GraphQL Playground by default, unless the
NODE_ENV
environment variable is set toproduction
, or if you explicitly configure it via theplayground
option to theApolloServer
constructor.Your Apollo Server 2 installation is vulnerable if any of the following is true:
playground: true
to theApolloServer
constructorplayground: {title: "Title"}
to theApolloServer
constructorplayground
option to theApolloServer
constructor, and theNODE_ENV
environment variable is not set toproduction
Apollo Server 1
Apollo Server 1 included
graphiql
instead ofgraphql-playground
.graphiql
isn't automatically enabled in Apollo Server 1: you have to explicitly call a function such asgraphiqlExpress
to enable it. Because Apollo Server 1 is not commonly used, we have not done a detailed examination of whether the integration between Apollo Server 1 andgraphiql
is vulnerable to a similar exploit. If you are still using Apollo Server 1, we recommend you disablegraphiql
by removing thegraphiqlExpress
call, and then upgrade to a newer version of Apollo Server.Patches and workarounds
There are several approaches you can take to ensure that your server is not vulnerable to this issue.
Upgrade Apollo Server
The vulnerability has been patched in Apollo Server 2.25.3 and Apollo Server 3.4.1. To get the patch, upgrade your Apollo Server entry point package to one of the fixed versions; this package may be
apollo-server
,apollo-server-express
,apollo-server-lambda
, etc. Additionally, if you depend directly onapollo-server-core
in yourpackage.json
, make sure that you upgrade it to the same version.Upgrade Playground version only
If upgrading to the latest version of Apollo Server 2 or 3 quickly will be challenging, you can configure your current version of Apollo Server to serve the latest version of the GraphQL Playground app. This will pin your app to serve a specific version of GraphQL Playground and you will not receive updates to it when you upgrade Apollo Server later, but this may be acceptable because GraphQL Playground is not actively maintained.
The way to do this depends on what version of Apollo Server you're using and if you're already configuring GraphQL Playground.
ApolloServerPluginLandingPageGraphQLPlayground
and passes it to the Apollo Server constructor in theplugins
array. Add the optionversion: '1.7.42'
to this call, so it looks like:playground
option: If you are using Apollo Server 2 and do not currently pass theplayground
option tonew ApolloServer
, add aplayground
option like so:playground: true
orplayground: {x, y, z}
: If you are using Apollo Server 2 and currently passtrue
or an object tonew ApolloServer
, pass theversion
option under theplayground
option like so:Disable GraphQL Playground
If upgrading Apollo Server or GraphQL Playground is challenging, you can also disable GraphQL Playground.
In Apollo Server 3, remove the call to
ApolloServerPluginLandingPageGraphQLPlayground
from yourApolloServer
constructor'splugins
array. This will replace GraphQL Playground with a simple splash page. See the landing page plugins docs for details.In Apollo Server 2, add
playground: false
to yourApolloServer
constructor:new ApolloServer({ playground: false })
. This will replace GraphQL Playground with an attempt to execute a GraphQL operation, which will likely display an error in the browser.If you disable GraphQL Playground, any users who rely on it to execute GraphQL operations will need an alternative, such as the Apollo Studio Explorer's account-free Sandbox.
Credit
This vulnerability was discovered by @Ry0taK. Thank you!
The fix to GraphQL Playground was developed by @acao and @glasser with help from @imolorhe, @divyenduz, and @benjie.
For more information
If you have any questions or comments about this advisory:
graphql-playground
advisoryapollo-server
repoGHSA-2p3c-p3qw-69r4
Impact
The graphql-upload npm package can execute GraphQL operations contained in
content-type: multipart/form-data
POST requests. Because they are POST requests, they can contain GraphQL mutations. Because they usecontent-type: multipart/form-data
, they can be "simple requests" which are not preflighted by browsers.If your GraphQL server uses
graphql-upload
and usesSameSite=None
cookies for authentication, then JS on any origin can cause browsers to send cookie-authenticated mutations to your GraphQL server, which will be executed without checking your CORS policy first. (The attack won't be able to see the response to the mutation if your CORS policy is set up properly, but the side effects of the mutation will still happen.)Additionally, if your GraphQL server uses
graphql-upload
and relies on network properties for security (whether by explicitly looking at the client's IP address or by only being available on a private network), then JS on any origin can cause browsers (which may be on a private network or have an allowed IP address) to send mutations to your GraphQL server, which will be executed without checking your CORS policy first. (This attack does not require your server to use cookies. It is in some cases prevented by some browsers such as Chrome.)Apollo Server 2 bundled
graphql-upload
and enabled it by default, so by default, Apollo Server 2 servers are vulnerable to these CSRF attacks. (Apollo Server 1 did not bundlegraphql-upload
. Apollo Server 3 no longer bundlesgraphql-upload
, although AS3's docs do document how to manually integrate withgraphql-upload
.) It is enabled even if your server makes no use of the upload functionality.If you are running Apollo Server 2 (older than v2.25.4) and do not specify
uploads: false
tonew ApolloServer
, then you are vulnerable to this CSRF mutation attack.We recently introduced an opt-in CSRF prevention feature in Apollo Server 3.7. This feature successfully protects against CSRF even if you have manually integrated your AS3.7 server with
graphql-upload
. However, this feature is not available for Apollo Server 2.Patches
If you are using Apollo Server 2 and do not actually use uploads in your schema (ie, the
Upload
scalar is not used as the argument to any field or in any input object definition, and you do not specifyuploads
tonew ApolloServer
), then upgrading to Apollo Server 2.25.4 will automatically disablegraphql-upload
in your server. This will fix the CSRF mutation vulnerability.Upgrading to v2.25.4 does still leave your server vulnerable to non-mutation CSRF attacks such as timing attacks against query operations. To protect yourself against these potentially lower impact CSRF attack, we encourage upgrading to Apollo Server v3.7 and enabling CSRF prevention. See the Apollo Server 3 migration guide and the CSRF prevention docs for details.
If you are actively using the uploads feature with Apollo Server 2, then upgrading to v2.25.4 will not disable the feature and you will still be vulnerable. You should instead upgrade to v3.7 and enable the CSRF prevention feature.
If you are manually integrating the
graphql-upload
package with any version of Apollo Server (or any Node GraphQL server) and need to continue using the feature, then you must enable some sort of CSRF prevention feature to fix this vulnerability. We recommend the CSRF prevention feature in Apollo Server 3.7.Workarounds
Instead of upgrading your Apollo Server 2 server, you can specify
uploads: false
tonew ApolloServer
to disable thegraphql-upload
integration and protect against CSRF mutations. (Only do this if you do not actually use the uploads feature in your server!) This will still leave your server vulnerable to non-mutation CSRF attacks such as timing attacks against query operations; you need to upgrade to v3.7 and enable CSRF prevention to protect against these attacks.Related work
Release Notes
apollographql/apollo-server (apollo-server)
### [`v2.25.3`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.25.2...apollo-server@2.25.3) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.25.2...apollo-server@2.25.3) ### [`v2.25.2`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.25.1...apollo-server@2.25.2) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.25.1...apollo-server@2.25.2) ### [`v2.25.1`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.25.0...apollo-server@2.25.1) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.25.0...apollo-server@2.25.1) ### [`v2.25.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.24.1...apollo-server@2.25.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.24.1...apollo-server@2.25.0) ### [`v2.24.1`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.24.0...apollo-server@2.24.1) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.24.0...apollo-server@2.24.1) ### [`v2.24.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.23.0...apollo-server@2.24.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.23.0...apollo-server@2.24.0) ### [`v2.23.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.22.2...apollo-server@2.23.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.22.2...apollo-server@2.23.0) ### [`v2.22.2`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.22.1...apollo-server@2.22.2) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.22.1...apollo-server@2.22.2) ### [`v2.22.1`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.22.0...apollo-server@2.22.1) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.22.0...apollo-server@2.22.1) ### [`v2.22.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.21.2...apollo-server@2.22.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.21.2...apollo-server@2.22.0) ### [`v2.21.2`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.21.1...apollo-server@2.21.2) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.21.1...apollo-server@2.21.2) ### [`v2.21.1`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.21.0...apollo-server@2.21.1) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.21.0...apollo-server@2.21.1) ### [`v2.21.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.20.0...apollo-server@2.21.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.20.0...apollo-server@2.21.0) ### [`v2.20.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.19.2...apollo-server@2.20.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.19.2...apollo-server@2.20.0) ### [`v2.19.2`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.19.1...apollo-server@2.19.2) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.19.1...apollo-server@2.19.2) ### [`v2.19.1`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.19.0...apollo-server@2.19.1) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.19.0...apollo-server@2.19.1) ### [`v2.19.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.18.2...apollo-server@2.19.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.18.2...apollo-server@2.19.0) ### [`v2.18.2`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.18.1...apollo-server@2.18.2) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.18.1...apollo-server@2.18.2) ### [`v2.18.1`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.18.0...apollo-server@2.18.1) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.18.0...apollo-server@2.18.1) ### [`v2.18.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.17.0...apollo-server@2.18.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.17.0...apollo-server@2.18.0) ### [`v2.17.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.16.1...apollo-server@2.17.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.16.1...apollo-server@2.17.0) ### [`v2.16.1`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.16.0...apollo-server@2.16.1) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.16.0...apollo-server@2.16.1) ### [`v2.16.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.15.1...apollo-server@2.16.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.15.1...apollo-server@2.16.0) ### [`v2.15.1`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.15.0...apollo-server@2.15.1) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.15.0...apollo-server@2.15.1) ### [`v2.15.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.14.5...apollo-server@2.15.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.14.5...apollo-server@2.15.0) ### [`v2.14.5`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.14.4...apollo-server@2.14.5) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.14.4...apollo-server@2.14.5) ### [`v2.14.4`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.14.3...apollo-server@2.14.4) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.14.3...apollo-server@2.14.4) ### [`v2.14.3`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.14.2...apollo-server@2.14.3) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.14.2...apollo-server@2.14.3) ### [`v2.14.2`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.14.1...apollo-server@2.14.2) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.14.1...apollo-server@2.14.2) ### [`v2.14.1`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.14.0...apollo-server@2.14.1) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.14.0...apollo-server@2.14.1) ### [`v2.14.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.13.1...apollo-server@2.14.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.13.1...apollo-server@2.14.0) ### [`v2.13.1`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.13.0...apollo-server@2.13.1) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.13.0...apollo-server@2.13.1) ### [`v2.13.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.12.0...apollo-server@2.13.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.12.0...apollo-server@2.13.0) ### [`v2.12.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.11.0...apollo-server@2.12.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.11.0...apollo-server@2.12.0) ### [`v2.11.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.10.1...apollo-server@2.11.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.10.1...apollo-server@2.11.0) ### [`v2.10.1`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.10.0...apollo-server@2.10.1) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.10.0...apollo-server@2.10.1) ### [`v2.10.0`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.16...apollo-server@2.10.0) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.16...apollo-server@2.10.0) ### [`v2.9.16`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.15...apollo-server@2.9.16) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.15...apollo-server@2.9.16) ### [`v2.9.15`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.14...apollo-server@2.9.15) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.14...apollo-server@2.9.15) ### [`v2.9.14`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.13...apollo-server@2.9.14) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.13...apollo-server@2.9.14) ### [`v2.9.13`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.12...apollo-server@2.9.13) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.12...apollo-server@2.9.13) ### [`v2.9.12`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.11...apollo-server@2.9.12) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.11...apollo-server@2.9.12) ### [`v2.9.11`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.10...apollo-server@2.9.11) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.10...apollo-server@2.9.11) ### [`v2.9.10`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.9...apollo-server@2.9.10) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.9...apollo-server@2.9.10) ### [`v2.9.9`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.8...apollo-server@2.9.9) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.8...apollo-server@2.9.9) ### [`v2.9.8`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.7...apollo-server@2.9.8) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.7...apollo-server@2.9.8) ### [`v2.9.7`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.6...apollo-server@2.9.7) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.6...apollo-server@2.9.7) ### [`v2.9.6`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.5...apollo-server@2.9.6) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.5...apollo-server@2.9.6) ### [`v2.9.5`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.4...apollo-server@2.9.5) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.4...apollo-server@2.9.5) ### [`v2.9.4`](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.3...apollo-server@2.9.4) [Compare Source](https://redirect.github.com/apollographql/apollo-server/compare/apollo-server@2.9.3...apollo-server@2.9.4)Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.