Reactjs Question posted in
The new location for the React Documentation can be found here.

Reactjs – Create React App content security policy is ignored

I have tried to add Auth0 to my application, which works locally but when I deploy to an S3 bucket I get the following error:

"Refused to connect to ‘https://dev-.us.auth0.com/oauth/token’ because it violates the following Content Security Policy directive: "default-src ‘self’". Note that ‘connect-src’ was not explicitly set, so ‘default-src’ is used as a fallback."

To resolve the issue I have tried to follow the instructions in this article under the ‘Using inline script or style’ header, however even though I can see the changes are being made to the relevant meta tag (see below, taken from the browser) I still get the same error.

<meta http-equiv="Content-Security-Policy" content="base-uri 'self'; object-src 'none'; script-src 'unsafe-inline' 'self' 'unsafe-eval' 'nonce-<hash>=='; style-src 'unsafe-inline' 'self' 'nonce-<hash>=='; connect-src 'self' https://dev-<hash>.us.auth0.com/">

The thing I don’t understand is that it looks like it is totally ignoring the meta tag, because I can see that connect-src is being set in the html used by the browser but then in the console it throws this error which claims that it has not been set. What could be going wrong here?

I tried to add a content security header to a create react app, and I expected the header to be used. However, the header is ignored.

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    I managed to find the solution. I was using cloudfront to serve the website and as part of the "ResponseHeadersPolicy" I had set an override on the 'Content-Security-Policy', which was conflicting with the meta tag I had set in the HTML document.

    The configuration I had used was taken from a guide so I had no idea what this header was until today. I suppose the takeaway is that one should always strive to understand what is being implemented instead of blindly following instructions.


  2. 0

    It sounds like you’re encountering an issue where the Content Security Policy (CSP) you’ve set in your HTML meta tag is not being respected when your application is deployed to an AWS S3 bucket. There are a few possible reasons for this issue, and I’ll guide you through some steps to troubleshoot and hopefully resolve it:

    1. Meta Tag vs. HTTP Header

    • The most effective way to set a CSP is through an HTTP header rather than a meta tag. This is particularly relevant in scenarios involving external API calls, like those to Auth0. Some browsers might enforce CSPs defined in HTTP headers more consistently than those in meta tags.
    • Solution: Configure your S3 bucket to send the CSP as an HTTP header. This can be done by setting the Content-Security-Policy header in the metadata of your S3 objects. If you are using CloudFront in front of S3, you can use a Lambda@Edge or CloudFront Functions to modify HTTP headers to include the CSP header.

    2. CSP Header Syntax Check

    • Ensure that the CSP rule includes all necessary sources. Your current policy seems correct, but re-check the domain used for Auth0 to ensure there’s no typo or misconfiguration.
    • Double-check: Make sure that the domain in the connect-src directive exactly matches the domain to which the application is trying to connect, including checking for any placeholders like <hash> which should be replaced with actual values.

    3. CSP Enforcement and Browser Cache

    • Browsers can aggressively cache CSPs, and changes might not be reflected immediately.
    • Solution: Clear your browser cache thoroughly or try accessing your application in an incognito window to see if the issue persists.

    4. Debugging CSP Issues

    • Use the browser’s developer tools to monitor network requests and responses. Check if any other CSP headers are being sent that might override what you’ve specified in the meta tag.
    • Inspect Headers: Look at the Network tab in developer tools to inspect the response headers of your initial page load. This can tell you whether the CSP header is being set correctly by the server.

    5. AWS S3/CloudFront Settings

    • If using CloudFront, check if there are any other settings or behaviors defined that might affect headers.
    • Configuration Check: Review any OAI (Origin Access Identity) settings or behaviors that strip headers or modify requests/responses.

    Action Plan

    1. Move CSP to HTTP Headers: Update your deployment process to include CSP rules in the HTTP headers rather than relying solely on the meta tag.
    2. Clear Cache and Retry: After updating the headers, clear your browser cache or test in incognito mode to ensure you’re seeing the latest version of your application.
    3. Inspect with Developer Tools: Use your browser’s developer tools to ensure that the CSP headers are being sent as expected and no conflicting headers are present.

    By following these steps, you should be able to pinpoint and resolve the issue with the CSP not being respected when your application is deployed to S3.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search