Releases: apollographql/apollo-server
@apollo/server@4.11.2
(No change; there is a change to the @apollo/server-integration-testsuite
used to test integrations, and the two packages always have matching versions.)
@apollo/server@4.11.1
Patch Changes
-
#7952
bb81b2c
Thanks @glasser! - Upgrade dependencies so that automated scans don't detect a vulnerability.@apollo/server
depends onexpress
which depends oncookie
. Versions ofexpress
older than v4.21.1 depend on a version ofcookie
vulnerable to CVE-2024-47764. Users of olderexpress
versions who callres.cookie()
orres.clearCookie()
may be vulnerable to this issue.However, Apollo Server does not call this function directly, and it does not expose any object to user code that allows TypeScript users to call this function without an unsafe cast.
The only way that this direct dependency can cause a vulnerability for users of Apollo Server is if you call
startStandaloneServer
with a context function that calls Express-specific methods such asres.cookie()
orres.clearCookies()
on the response object, which is a violation of the TypeScript types provided bystartStandaloneServer
(which only promise that the response object is a core Node.jshttp.ServerResponse
rather than the Express-specific subclass). So this vulnerability can only affect Apollo Server users who use unsafe JavaScript or unsafeas
typecasts in TypeScript.However, this upgrade will at least prevent vulnerability scanners from alerting you to this dependency, and we encourage all Express users to upgrade their project's own
express
dependency to v4.21.1 or newer.
@apollo/server-integration-testsuite@4.11.2
@apollo/server-integration-testsuite@4.11.1
Patch Changes
-
#7952
bb81b2c
Thanks @glasser! - Upgrade dependencies so that automated scans don't detect a vulnerability.@apollo/server
depends onexpress
which depends oncookie
. Versions ofexpress
older than v4.21.1 depend on a version ofcookie
vulnerable to CVE-2024-47764. Users of olderexpress
versions who callres.cookie()
orres.clearCookie()
may be vulnerable to this issue.However, Apollo Server does not call this function directly, and it does not expose any object to user code that allows TypeScript users to call this function without an unsafe cast.
The only way that this direct dependency can cause a vulnerability for users of Apollo Server is if you call
startStandaloneServer
with a context function that calls Express-specific methods such asres.cookie()
orres.clearCookies()
on the response object, which is a violation of the TypeScript types provided bystartStandaloneServer
(which only promise that the response object is a core Node.jshttp.ServerResponse
rather than the Express-specific subclass). So this vulnerability can only affect Apollo Server users who use unsafe JavaScript or unsafeas
typecasts in TypeScript.However, this upgrade will at least prevent vulnerability scanners from alerting you to this dependency, and we encourage all Express users to upgrade their project's own
express
dependency to v4.21.1 or newer. -
Updated dependencies [
bb81b2c
]:- @apollo/server@4.11.1
@apollo/server@4.11.0
Minor Changes
-
#7916
4686454
Thanks @andrewmcgivery! - AddhideSchemaDetailsFromClientErrors
option to ApolloServer to allow hiding 'did you mean' suggestions from validation errors.Even with introspection disabled, it is possible to "fuzzy test" a graph manually or with automated tools to try to determine the shape of your schema. This is accomplished by taking advantage of the default behavior where a misspelt field in an operation
will be met with a validation error that includes a helpful "did you mean" as part of the error text.For example, with this option set to
true
, an error would readCannot query field "help" on type "Query".
whereas with this option set tofalse
it would readCannot query field "help" on type "Query". Did you mean "hello"?
.We recommend enabling this option in production to avoid leaking information about your schema to malicious actors.
To enable, set this option to
true
in yourApolloServer
options:const server = new ApolloServer({ typeDefs, resolvers, hideSchemaDetailsFromClientErrors: true, });
@apollo/server-integration-testsuite@4.11.0
Patch Changes
- Updated dependencies [
4686454
]:- @apollo/server@4.11.0
@apollo/server@4.10.5
@apollo/server-integration-testsuite@4.10.5
@apollo/server@4.10.4
Patch Changes
- #7871
18a3827
Thanks @tninesling! - Subscription heartbeats are initialized prior to awaiting subscribe(). This allows long-running setup to happen in the returned Promise without the subscription being terminated prior to resolution.
@apollo/server-integration-testsuite@4.10.4
Patch Changes
- Updated dependencies [
18a3827
]:- @apollo/server@4.10.4