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 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.
apollo-server-core: You may now specify your Studio graph as a graph ref (id@variant) via the APOLLO_GRAPH_REF environment variable or new ApolloServer({apollo: {graphRef}}) instead of specifying graph ID and graph variant separately. The apollo object passed to plugin serverWillStart and to gateway load now contains a graphRef field.
apollo-server-core: Fix a race condition where schema reporting could lead to a delay at process shutdown. [PR #5222](apollographql/apollo-server#5222)
apollo-server-core: Allow the Fetch API implementation to be overridden for the schema reporting and usage reporting plugins via a new fetcher option. [PR #5179](apollographql/apollo-server#5179)
apollo-server-core: The server.executeOperation method (designed for testing) can now take its query as a DocumentNode (eg, a gql-tagged string) in addition to as a string. (This matches the behavior of the apollo-server-testingcreateTestClient function which is now deprecated.) We now recommend this method instead of apollo-server-testing in our docs. [Issue #4952](apollographql/apollo-server#4952)
apollo-server-testing: Replace README with a deprecation notice explaining how to use server.executeOperation instead. [Issue #4952](apollographql/apollo-server#4952)
v2.24.1
apollo-server-core: Fix a typo that could lead to TypeScript compilation when combined with a recent version of @types/node. (This bug had no runtime effect.) [PR #5149](apollographql/apollo-server#5149)
v2.24.0
apollo-server-core: Apollo Studio usage reporting uses a more efficient format which sends fewer detailed traces to Apollo's server. This change should not have a major effect on the experience of using Apollo Studio. [PR #4142](apollographql/apollo-server#4142)
apollo-server-cache-redis@1.4.0: New BaseRedisCache class which takes an ioredis-compatible Redis client as an argument. The existing classes RedisCache and RedisClusterCache (which pass their arguments to ioredis constructors) are now implemented in terms of this class. This allows you to use any of the ioredis constructor forms rather than just the ones recognized by our classes. This also fixes a long-standing bug where the Redis cache implementations returned a number from delete(); it now returns a number, matching what the KeyValueCache interface and the TypeScript types expect. [PR #5034](apollographql/apollo-server#5034) [PR #5088](apollographql/apollo-server#5088) [Issue #4870](apollographql/apollo-server#4870) [Issue #5006](apollographql/apollo-server#5006)
apollo-server-lambda: Fix regression in v2.21.2 where thrown errors were replaced by throwing the JS Error class itself. [PR #5085](apollographql/apollo-server#5085)
apollo-server-lambda: Explicitly support API Gateway payloadFormatVersion 2.0. Previously some codepaths did appropriate checks to partially support 2.0 and other codepaths could lead to errors like event.path.endsWith is not a function (especially since v2.21.1). Note that this changes the TypeScript typing of the onHealthCheck callback passed to createHandler to indicate that it can receive either type of event. If you are using TypeScript and care about having a precise typing for the argument to your onHealthCheck callback, you should determine which payload format you want to support and write new ApolloServer<APIGatewayProxyEvent>(...) or new ApolloServer<APIGatewayProxyEventV2>(...) (importing these types from aws-lambda), or differentiate between the two formats by checking to see if 'path' in event. [Issue #5084](apollographql/apollo-server#5084) [Issue #5016](apollographql/apollo-server#5016)
v2.22.2
apollo-server-core: Fix a regression in v2.22.0 where combining apollo-server-core v2.22 with an older version of an integration package could lead to startup errors like called start() with surprising state invoking serverWillStart. The fix involves changing the semantics of the protected willStart method (which is left in only for backwards compatibility). [Issue #5065](apollographql/apollo-server#5065) [Issue #5066](apollographql/apollo-server#5066) [PR #5073](apollographql/apollo-server#5073)
v2.22.1
apollo-server-core: Fix a regression in v2.22.0 where startup errors could be thrown as part of the GraphQL response instead of redacted in one edge case. [PR #5064](apollographql/apollo-server#5064)
v2.22.0
Improve startup error handling by ensuring that your server has loaded its schema and executed its serverWillStart handlers successfully before starting an HTTP server. If you're using the apollo-server package, no code changes are necessary. If you're using an integration such as apollo-server-express that is not a "serverless framework", you can insert await server.start() between server = new ApolloServer() and server.applyMiddleware. (If you don't call server.start() yourself, your server will still work, but the previous behavior of starting a web server that may fail to load its schema still applies.) The serverless framework integrations (Lambda, Azure Functions, and Cloud Functions) do not support this functionality. While the protected method willStart still exists for backwards compatibility, you should replace calls to it with start or the new protected method ensureStarting. [PR #4981](apollographql/apollo-server#4981)
v2.21.2
apollo-server-core: The SIGINT and SIGTERM signal handlers installed by default (when not disabled by stopOnTerminationSignals: false) now stay active (preventing process termination) while the server shuts down, instead of letting a second signal terminate the process. The handlers still re-signal the process after this.stop() concludes. Also, if this.stop() throws, the signal handlers will now log and exit 1 instead of throwing an uncaught exception. [Issue #4931](apollographql/apollo-server#4931)
apollo-server-lambda: Refactor the handler returned by server.createHandler so that if it is not passed a callback, it acts as an async handler instead of a non-async handler. This means you can wrap it in your own async handler without having to create a callback, and makes the code more maintainable. [Issue #1989](apollographql/apollo-server#1989) [PR #5004](apollographql/apollo-server#5004)
The debug option to new ApolloServer (which adds stack traces to errors) now affects errors that come from requests executed with server.executeOperation (and its wrapper apollo-server-testing), instead of just errors that come from requests executed over HTTP. [Issue #4107](apollographql/apollo-server#4107) [PR #4948](apollographql/apollo-server#4948)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme
Additionally, you can set the following in the `.dependabot/config.yml` file in this repo:
- Update frequency
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)
Bumps apollo-server-core from 2.4.8 to 2.25.0. This update includes a security fix.
Vulnerabilities fixed
Sourced from The GitHub Security Advisory Database.
... (truncated)
Changelog
Sourced from apollo-server-core's changelog.
... (truncated)
Commits
42983b0
Release19572d7
Release6396938
Remove deprecation warningc8c0748
Release909bb3f
Allow specifying graph refs instead of ID/variant (#5241)cd779db
Deprecate apollo-server-testing; allow ASTs for executeOperation (#5238)d6b1bd4
apollo-server-core: Add fetcher option to schema and usage reporting (#5179)a43c411
Fix bug in schemaReporter.ts where stop() called while sendOneReportAndSchedu...9e1bf7d
Releasebd44a4c
usage reporting: fix typo in Buffer.byteLength argument (#5149)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase
.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) - `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme Additionally, you can set the following in the `.dependabot/config.yml` file in this repo: - Update frequency - Out-of-range updates (receive only lockfile updates, if desired) - Security updates (receive only security updates, if desired)