SonarQube 10.0 cloudflare CSP issue

SonarQube
1

Issue

Hello,
We’ve updated our SonarQube instance from 9.8 to 10.0 (update to 9.9 and then to 10) + java JDK from 11 to 17.
Post upgrade our web interface worked for 2-3 hours and then got stuck on loading screen with the following console error message:

Refused to load the script 'https://static.cloudflareinsights.com/beacon.min.js/vb26e4fa9e5134444860be286fd8771851679335129114' because it violates the following Content Security Policy directive: "script-src 'self'". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback

It looks like there is a CSP issue in sonar as also explained here
However, sonar-scanner can communicate with SonarQube in our CI pipelines.

The issue seems to be caused by SONAR-18809

What we’ve tried so far

  • Restarting the sonarqube Linux service: the logs are clear, with no error, but still the same issue.
  • Cloudflare cache purge
  • Browser cache purge

What seems to temporarily work

  • Accessing SonarQube via Edge (Safari, Chrome and Firefox got stuck on loading). In Edge there is not console error thrown.
  • After Cloudflare cache purge in Chrome incognito the console still throws the above console error, but the screen doesn’t get stuck on loading, allowing you to log in. If however we logout, then it gets stuck in loading again

Technical details:

  • Database: PostgreSQL 13.1
  • JavaJDK: 17.0.6
  • SonarQube 10.0.0.68432
  • SonarQube deployed via zip as a Linux service
  • SonarQube DNS is managed by Cloudflare
  • We do not use any SonarQube plugin
4

Hello @Andumy thanks for reporting this.

In 10.0 we made stricter and more secure the SonarQube Cross Site Policy. It seems that cloudflare is injecting into the SonarQube page a script that is being blocked at the moment.
Can you share how this gets materialized in the code of the web pages of your SonarQube instance?

5

Hey, I’m not exactly sure I know how to answer your question. I would assume that cloudflare process the http response and inject the script before forwarding it to the client.

After some more investigations, it seems like the issue is related to Cloudflare’s Auto Minify feature that minifies js and css.

In Sonar’s homepage, I saw 2 assets loaded

<link rel="stylesheet" href="/js/outPKBKIYFT.css" />
<script type="module" src="/js/out4CRO2ANZ.js"></script>

These seem to be processed by Cloudflare and served via cache.
This would explain why after clearing the cache for a short period of time it would work since they were not yet cached back by Cloudflare.

We currently disabled Cloudflare’s auto minify for the sonar uri, and it seems that now it’s working again.

I’m not exactly sure if this should be considered a solution or not, so I’ll leave the issue open for now.

6

Thanks for sharing the solution you put in place.
Those files are probably already cached by the browser too, so this extra caching I am not sure how impactful it can be.

We will keep the situation monitored in order to understand what is the impact of this change, but the CSP rules in place now are like the standard for ensuring proper cross-site scripting protection.

1 Like