Add "Content-Security-Policy" header

(Kevin Sheehan) #1

The “Content-Security-Policy” header is designed to modify the way browsers render pages, and thus to protect from various cross-site injections, including Cross-Site Scripting. It is important to set the header value correctly, in a way that will not prevent proper operation of the web site. For example, if the header is set to prevent execution of inline JavaScript, the web site must not use inline JavaScript in it’s pages.

To protect against Cross-Site Scripting, it is important to set the ‘default-src’ policy, or ‘script-src’ AND ‘object-src’ with proper values. Insecure values such as '*&quot, 'data:&quot, 'unsafe-inline&quot, or ‘unsafe-eval’ should be avoided.

In addition, to protect against Cross-Frame Scripting or clickjacking, it is important to set the ‘frame-ancestors’ policy with proper values. Insecure values such as ‘*’ or ‘data:’ should be avoided.

(G Ann Campbell) #2


It’s not clear to me what you’re suggesting. Do SonarQube’s headers need tweaking, or are you suggesting a new rule?


(Kevin Sheehan) #3

The CSP header is missing - we are asking it be added.

(Lars Svensson) #4

Hi Kevin,

Thanks for notifying us about the CSP header - we are going to discuss it internally the next days. I will let you know the outcome of the discussions.

SonarSource AppSec team

(Lars Svensson) #5

Hi Kevin,

A quick follow up:

As SonarQube currently fetches resources from several different external hosts, many of them in a dynamic way, setting a meaningful CSP header turned out to be a non-trivial task.

We are convinced that we need to implement it but it requires a bit more thought. We aim to do it this year at least.


(Kevin Sheehan) #6

Thanks so much for the update Lars!