azure-ad-msalmsal.jsmsalmsal-react

CSP Error: Refused to connect to Microsoft OAuth token endpoint due to default-src policy


I'm encountering a Content Security Policy (CSP) error in production only when trying to authenticate via Microsoft OAuth. The same flow works perfectly in development, testing, and preproduction environments.

Here’s the error message from the browser console:

Refused to connect to 'https://login.microsoftonline.com/1234/oauth2/v2.0/token?client-request-id=1234' because it violates the following Content Security Policy directive: "default-src 'self' data: 'unsafe-inline' 'unsafe-eval' XYZ.de *.XYZ.de". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback.

It seems the request is being blocked because my CSP doesn't explicitly allow connections to external domains like login.microsoftonline.com.

Questions: Why would this CSP issue appear only in production?

What is the best way to configure the CSP to allow this token request without compromising security?

Is explicitly setting connect-src in the CSP header sufficient to fix this?

Could a CDN or production web server (e.g., nginx, Apache, etc.) be altering or overriding the CSP?

Any help or experience with similar production-only CSP issues would be greatly appreciated!

"dependencies": { "@azure/msal-browser": "^4.10.0", "@azure/msal-react": "^3.0.9", }


Solution

  • Questions: Why would this CSP issue appear only in production?

    Because on your dev env you either do not have a CSP specification at all, or the domain was already handled.

    What is the best way to configure the CSP to allow this token request without compromising security?

    I will forget about "best" and will answer the "how". CSP whitelists domains you trust. So if you trust ogin.microsoftonline.com - and you trust it with the login -, then whitelist it in CSP.

    Is explicitly setting connect-src in the CSP header sufficient to fix this?

    It could be. Set it, whitelist the domain(s) that you trust and see whether there are further issues.

    Could a CDN or production web server (e.g., nginx, Apache, etc.) be altering or overriding the CSP?

    In some systems they are overriden. If you are unsure, either ask someone who knows or look into the configuration.

    Any help or experience with similar production-only CSP issues would be greatly appreciated!

    You could do well to reproduce the issue locally, that is, have the same (wrong) CSP on your local temporarily to reproduce the issue and then fix it on your local. Once you succeed, it should work on live too. BUT: back up your settings, especially the CSP directives from live before you do any change.