-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable suggestions in errors message #3919
Comments
The tool Shapeshifter uses that leakage of information to identify fields automatically. View the tool in action later in the same talk as previously linked. |
This is a hard requirement from the security team at my client. If no resolution is found we my need to abandon Apollo server, which would be devastating to our project. Please make this available if possible, or provide documentation on how to configure. Thanks! |
@supermonkeybrainz honestly I think you probably better off summiting a fix for that. I don't really think the Apollo team cares about you since you don't bring them any revenue (no offence). If this client plans to use the commercial offering of Apollo and this is a deal breaker, I suggest you contact their customer reps. |
@Sytten I was admittedly a little overdramatic in my post, but I wanted to convey the seriousness of this issue. There are workarounds (express middleware, error formatter, etc.). I did look into fixing this. After further digging I discovered the issue is in the graphql library. There is an existing issue. Not much the Apollo folks (or myself) can do here until that is fixed. |
@supermonkeybrainz sort of a hack, but you could use either fork
|
Just found a work around for this and thought i'd share. Use the FormatError feature and mask any errors you don't want the client seeing. In my case i mask them all.
|
perhaps a more suited workaround should be : import { ValidationError } from "apollo-server-express"
import { GraphQLError, GraphQLFormattedError } from "graphql"
import { NODE_ENV } from "../constants"
export const formatGqlError = (error: GraphQLError): GraphQLFormattedError<Recor
if (process.env.NODE_ENV !== NODE_ENV.DEV) {
if (error instanceof ValidationError) {
return new ValidationError("Invalid request.")
}
} |
This fix needs to be implemented in graphql-js. There's an issue tracking it in graphql/graphql-js#2247 If that is implemented, we would change This is not currently actionable, so I'm going to close it; if the graphql-js issue gets fixed and we don't already do this, feel free to ping or open a new issue. |
…schema information (#7916) It was previously discussed (see: #3919) to wait for graphql/graphql-js#2247 to close, however, that issue has not moved in years and in the mean time libraries and frameworks seem to have opted for implementing their own solutions (E.g. https://github.com/Escape-Technologies/graphql-armor/blob/main/packages/plugins/block-field-suggestions/src/index.ts). This should be a very low impact change that achieves the goal that would also be easy enough to rip out if this gets properly implemented in graphql-js later. Adds `hideSchemaDetailsFromClientErrors` option to ApolloServer to allow hiding of these suggestions. Before: `Cannot query field "helloo" on type "Query". Did you mean "hello"?` After: `Cannot query field "helloo" on type "Query".` Fixes #3919
Context
We have some mutation defined:
The user sends the following query:
The server will response with an error maintaining in the message:
"message": "Cannot query field \"updateUserDetil\" on type \"Mutation\". Did you mean \"updateUserDetail\"?",
The problem
In case of a private API, we generally want to avoid leaking information about our API. Disabling the introspection is a good step, but the recommendations are leaking some information that can be used by attackers. This talk discuss this issue (from the perspective of a pentester).
Propositions
The text was updated successfully, but these errors were encountered: