Graphql introspection with masterkey does not work when NODE_ENV is production

[Stovedal]

New Issue Checklist

• Report security issues confidentially.
• Any contribution is under this license.
• Before posting search existing issues.

Issue Description

The GQL introspection endpoint is blocked for environments with NODE_ENV=production even when requesting it with masterkey.

As I understand it from this PR introspection should always work when masterKey is used, but since the introspection boolean on ApolloServer defaults to false the request is blocked even though it's not stopped by the introspection plugin.

Steps to reproduce

Run server without setting graphQLPublicIntrospection to true, set NODE_ENV to production and run an introspection request with master key.

Actual Outcome

{"errors":[{"message":"GraphQL introspection is not allowed by Apollo Server, but the query contained __schema or __type. To enable introspection, pass introspection: true to ApolloServer in production","locations":[{"line":2,"column":3}],"extensions":{"validationErrorCode":"INTROSPECTION_DISABLED","code":"GRAPHQL_VALIDATION_FAILED"}}]}

Expected Outcome

< introspection result >

Environment

7.5.3

Server

• Parse Server version: 7.5.3
• Operating system: MacOS
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): Heroku

Database

• System (MongoDB or Postgres): Mongo
• Database version: 7
• Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): MongoDB Atlas

Client

• SDK (iOS, Android, JavaScript, PHP, Unity, etc): FILL_THIS_OUT
• SDK version: FILL_THIS_OUT

Logs

[parse-github-assistant]

🚀 Thanks for opening this issue!

❌ Please fill out all fields with a placeholder FILL_THIS_OUT. If a field does not apply to the issue, fill in n/a or delete the line.

[emil19]

Hijacking to suggest adding the possibility to have more granular control of allowing introspection or not by passing a function into the graphql configuration options.

This function would have access to the request context and return a boolean.

A use case for this would be to have a special key as passed as a separate header which has lower privileges than the master key. This would allow for more broad access to introspection without granting access to the master key or having public access.

[mtrezza]

Good idea. Regarding master key, the docs say:

All the schemas methods require MasterKey.

Therefore I'd say the master key should also always be allowed to use introspection. We may need to extend the access scopes table with a new "Schema" column since it's meta data and we haven't defined that yet.

Scope	Internal data	Read-only data (1)	Custom data	Schema	Restricted by CLP, ACL	Key
Internal	r/w	r/w	r/w	r/w	no	maintenanceKey
Master	-/-	r/-	r/w	r/w	no	masterKey
ReadOnlyMaster	-/-	r/-	r/-	r/-	no	readOnlyMasterKey
Session	-/-	r/-	r/w	-/-	yes	sessionToken

[Moumouls]

i think it will be fixed in the apollo update PR, it's weird because we have test cases

[Moumouls]

A use case for this would be to have a special key as passed as a separate header which has lower privileges than the master key. This would allow for more broad access to introspection without granting access to the master key or having public access.

@emil19 An even better idea could be to expose the full Apollo Server configuration as a Parse Server option.

That way, Parse Server would simply pass the configuration to Apollo, and wouldn’t need to maintain or define specific features itself.

@mtrezza The issue, however, is that any breaking changes in Apollo Server would also result in breaking changes for Parse Server.

I’m not sure Parse Server is ready yet for a full inversion of control, where we could pass an ApolloServer instance into the ParseGraphQLServer.

[mtrezza]

The issue, however, is that any breaking changes in Apollo Server would also result in breaking changes for Parse Server.

I think it depends on risks and benefits of that approach. I don't see an issue with exposing apollo, if it saves us maintenance efforts. The breaking changes need to be addressed anyway, to keep apollo on latest major versions, if I followed your thoughts correctly. What would that mean for DX? I suppose the GraphQL endpoint would then operate outside some of Parse Server's security mechanisms?

[Moumouls]

@Stovedal the bug will be fixed here: #9888

I improved the coverage of the introspection protection system.

[Moumouls]

@mtrezza I haven’t yet investigated the full impact of using Inversion of Control (IoC) by injecting an Apollo configuration or instance through Parse Server. However, it could be a great approach to reduce maintenance and expose Apollo’s full set of features directly to developers, there’s really no better approach than IoC.

The only disadvantage of this approach is that we would support IoC specifically for Apollo. The goal would not be to support every GraphQL framework. From my point of view, this isn’t an issue, as Apollo is the most mature and well-maintained GraphQL server available.