Support Forums

Content-Security-Policy inline-script error with Netlify Internal Redirect

Hi, I’m making my way through a React app configuration for a Netlify Internal Redirect. The destination site of the redirect seems to require specific Content-Security-Policy settings for a number of sources. I’ve made my way through configuring rules for all of the blocked sources except for the ones in the screenshot. Adding app.netlify.com to my CSP rules doesn’t seem to change anything. What should I do to resolve this?

Note the issue from the screenshot can be seen at the destination domain without passing through the redirect:


Hi @dminer,

Could you try to add that as a <meta> tag instead of a HTTP header to see if it makes a difference?

It didn’t seem to make a difference, but I’m noticing that it only occurs when we visit the desintation site directly; it doesn’t happen when we visit the destination site via the Netlify proxy:


Is it normal to need Access-Control-Allow-Origin and Content-Security-Policy headers for the destination site? We don’t use them for the original site. If they are needed to get the destination site to load the same sources as the original site, then does that indicate that the configuration is incorrect?

Hi @dminer – sorry for the noise. Those reports are being generated from our Collaborative Deploy Previews feature. They errors in console are coming from a recent header that we set. Note that the header is Content-Security-Policy-Report-Only (and not the Content-Security-Policy header), so resources are only getting logged, not blocked. Regardless, we still have some work to do to clean up those logs – they shouldn’t be appearing in your console. You can confirm that your site is OK by visiting a branch deploy or a production deploy of your site – those errors shouldn’t be appearing there.

Again, I apologize for the noise, but these errors in console are safe to ignore. We hope to be clearing up those report violations soon.

Thanks for clearing all of this up and helping us move forward, @jasonb; this is really helpful!
I can confirm that the errors are not appearing in a branch deploy like you describe.
No worries about the construction dust; we appreciate all the hard work.

1 Like