graphql-playground: Not loading due to Content Security Policy Directive on CDN requests

I had the same problem and solved it. This is a problem with setting the “Content-Security-Policy” header value that the web server responds. need to delete or modify the setting.

In my case, the helmet module was responding, and I solved it by modifying it as follows.

app.use(helmet({ contentSecurityPolicy: (process.env.NODE_ENV === 'production') ? undefined : false }));

For those of you running into this after upgrading helmet to v5 or higher (as I did), you will also get a console error and blocked response because of COEP/CORP headers (in Chrome, but not in Firefox). This happens because the initial request to cdn.jsdelivr.com yields a 307 Temporary Redirect from http to https (because of the HSTS configuration on the jsdelivr side). This redirect itself does not contain the proper CORP headers – I think.

I have addressed this at jsdelivr’s repo: https://github.com/jsdelivr/jsdelivr/issues/18201#issuecomment-1012912236

To circumvent this, also disable the crossOriginEmbedderPolicy header:

  app.use(helmet({ contentSecurityPolicy: false, crossOriginEmbedderPolicy: false }))

Disabling contentSecurityPolicy for development is not the best idea, since developers will not notice something does not work until it’s in the production.

I think the graphql playground should have all the scripts as npm development dependencies and not hosted on cdn.jsdelivr.net.

Another solution is whitelisting cdn.jsdelivr.net in CSP, but it is not a good idea, since anyone can upload anything on jsdelivr.net, which makes the CSP useless.

I had the same problem and solved it. This is a problem with setting the “Content-Security-Policy” header value that the web server responds. need to delete or modify the setting.

In my case, the helmet module was responding, and I solved it by modifying it as follows.

app.use(helmet({ contentSecurityPolicy: (process.env.NODE_ENV === 'production') ? undefined : false }));

Is there any issue in setting contentSecurityPolicy to undefined in production?

This should be reopened. The root of issue lays in insecure playground implementation - this should be addressed based on issues reported by CSP checks. Like get rid of all inline scripts/styles/fonts/images and use whitelisted domain only or locally served files. Then it should be simple to configure helmet without using insecure directives/options.

I just spent a good 2 days of my life that I will never get back trying to figure this out – the config in the nestjs docs worked beautifully. Thank you!

I have filed a bug at Chrome for this (the COEP / CORP headers) issue, as it seems that this is not the way the browser should handle this (i.e.: HSTS redirects should be internal to the browser and not expect CORP headers):

https://bugs.chromium.org/p/chromium/issues/detail?id=1287500

EDIT: A fix has been made Jan 19, 2022 👍

If you want to still have CSP headers but limit it somewhat (instead of disabling entirely)

  const devContentSecurityPolicy = {
    directives: {
      scriptSrc: ["'self'", "'unsafe-inline'", 'https://cdn.jsdelivr.net'],
      imgSrc: ["'self'", 'data:', 'https://cdn.jsdelivr.net'],
    },
  };

  app.use(
    helmet({
      // when undefined it will load the default option: https://github.com/graphql/graphql-playground/issues/1283#issuecomment-723705276
      contentSecurityPolicy: IS_DEV ? devContentSecurityPolicy : undefined,
    }),
  );

@kweij you’re the hero of the day, thanks for taking the time to add this precise comment, thanks!!!

https://github.com/helmetjs/helmet/blob/d491d281eb1cc55380046532d24fbc314af836e0/index.ts#L69-L75 undefined is the default. When undefined, it is enabled as the default option.

Well you don’t want to disable CSP headers for development envs, because you will miss other issues with it, up until production, on your API. Therefore your playground is not working anyway or you introduce security issue with header policies to the whole app or you waste some resources and create a separate app with different header policy just for playground. The issue is even more serious if you plan to use playground as public and open API tool.

The other approach for this might be generating proper exclusions for CSP headers, I think.

@johnson-elugbadebo oh man thanks this works so fine!

for anyone who might be interested, here is an example of how to load the new graphiql as an apollo server plugin:

https://codesandbox.io/p/sandbox/apollo-server-w-graphiql-8xbnju

we are pushing forward on adding the monaco-graphql mode that I created as well for 4.0.0

Adding headers to ApolloServerPluginLandingPageLocalDefault options worked for me. Versions:

"@apollo/server": "^4.0.3",
"@apollo/server-plugin-landing-page-graphql-playground": "^4.0.0",

ApolloServerPluginLandingPageLocalDefault({
   headers: {
      "Content-Security-Policy": "default-src 'self' https://apollo-server-landing-page.cdn.apollographql.com;",
   },
}),

@tconroy I could get rid of a view errors with passing these options:

const playground: PlaygroundConfig = {
  cdnUrl: 'https://cdn.jsdelivr.net/npm',
  faviconUrl: '',
};

The two errors related to index.css and middleware.js still remain.

    //...
    "apollo-server-core": "^2.18.1",
    "apollo-server-express": "^2.18.1",
    "express": "^4.17.1",
    "graphql": "^15.3.0",
    "graphql-tools": "^6.2.3",