Add "Content-Security-Policy" header

SonarQube Server / Community Build
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.

2

Hi,

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

 
Ann

1 Like
3

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

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.

Regards,
Lars
SonarSource AppSec team

3 Likes
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.

Regards,
Lars

4 Likes
6

Thanks so much for the update Lars!

7

@sonarsourcers, any update on the CSP Header? In particular, adding some of the more “safe” representations such as

Content-Security-Policy: frame-ancestors ‘self’

seem prudent. There may be others.

8

Any updates on this @ganncamp with the 8.6 LTS? Our security teams ping us periodically on the status, so, we’re simply passing it along. Thanks in advance!

9

Hi,

8.6 is not the LTS. We anticipate releasing the LTS at the end of 2021Q1.

 
HTH,
Ann

1 Like
12

Was this eventually implemented? We’ve gone past LTS, v8.9 and have implemented v9.4. Curious if CSP Headers were included in any of the updates since this was brought up. Thanks for any updates!

13

Hi,

Jumping down the internal rabbit hole, I don’t see indications of any work done on this. I’ll do some pinging…

 
Ann

16

Hi,

So… it looks like this got lost in the shuffle.

Our internal assessment included this:

not having it does not make us vulnerable in itself, but it is a recommended measure as it helps to implement the principle of least privilege

Which may help explain why it was overlooked.

And, now that it’s back on the radar, we’re probably going to try to do it for the next LTS. So thanks very much for the ping!

 
Ann

1 Like
17

Thank you!

18

Hi, is there an update on CSP? Has support for it been added? Thanks

21

Hi @itsthomas,

This is not yet supported. We’d like to start adding a first CSP before the next LTS and iteratively and carefully introduce other CSPs in the following SonarQube versions.

Chris

22

Hi Team, Is there an update on CSP? Has these header has been added? Thanks

26

Hi @Harish.s,

I’m happy to inform you that SonarQube 9.9 LTS is adding the CSP header (SONAR-17619). We’ve also made an additional improvement to strengthen the security policy in 10.0 (SONAR-18809).
You’ll find references to these changes in the 9.8 announcement and in the 10.0 announcement.

Chris

1 Like
27

Hi team ,
Are there plans to add a frame-ancestors policy as well?

Yann

28

Hi @ChampiYann,

Welcome to the community!

Could you create a new thread with your use case for this, please?

 
Thx,
Ann