Whonix website security rating - "B" (Mozilla Observatory) - Content Security Policy (CSP)

As http://kkkkkkkkkk63ava6.onion/wiki/Whonix:Privacy_policy is locked from editing, please add to the “Technical Information” table →

HTTP Headers & Content Security

Then (in red):

D Rating. Analyse your HTTP response headers Content Security Policy is not enacted, X-Content-Type-Options are vulnerable to MIME-sniffing, and Referrer Policy is not set.

Also suggest adding to the table →

Server Security

Then (in yellow or red):

The server header is advertising the software being run on the server. Analyse your HTTP response headers

Maybe change HSTS to yellow also due to Mozilla Observatory not liking the strict transport security settings (but not specifying why).

Transparency with users and all that. Right now the table makes it look like everything is fine and dandy, when it isn’t.

Also, a privacy policy should really be available in English. Shall I run that German stuff on the same page through Bing translator and fix up the quirky English result?

1 Like

That’s the same thing as Content-Security-Policy.

I don’t see where they are. But even if they did, with all due respect for Mozilla, we shouldn’t take it without sensible justification.


No, it’s only there for legal purposes.

No. It’s legal text. To be effective, it needs to be in German language. Until something or someone has been found to take responsibility to set up a better legal framework for Whonix. The editing of Privacy Policy - Whonix is blocked, because we cannot accept changes to the legal text. (Similar to editing the text of licenses such as GPL - very bad idea.)

The technical information part however is volunteer, not required for legal reasons. Therefore I have split it into a separate template https://www.whonix.org/wiki/Template:Whonix.org_security in case you wish to edit it further.

Also addded:

Certificate Authority (CA) Pinning

HTTP Public Key Pinning

1 Like

You have entered just whonix.org to be scanned which is equal to http://whonix.org and the HTTP response does indeed include a HSTS header but I wouldn’t consider this to be a big problem because browsers should just ignore it (RFC 6797, sect. 8.1) on the first request and accept it after the redirect to HTTPS. If you scan https://whonix.org it doesn’t complain about the HSTS header:

The “Onebox” fearure seems to be unable to handle &-signs correctly, they show up encoded as HTML-entity & in the URL. Here is the correct link: https://securityheaders.io/?q=https%3A%2F%2Fwhonix.org%2F&hide=on&followRedirects=on

1 Like


You have entered just whonix.org to be scanned which is equal to
http://whonix.org and the HTTP response does indeed include a HSTS
header but I wouldn’t consider this to be a big problem because […]

I would consider that a feature.

If it was a feature that browsers would support you could inject this header in the HTTP traffic to execute a denial of service attack on websites that don’t have (full) HTTPS support, which is probably the reason why browsers are supposed to ignore it.
It also wouldn’t have any real advantage over being redirected to HTTPS and then getting an HSTS header which you can trust.
But adding it doesn’t really harm as long as HTTPS is supported and/or browsers keep ignoring it .

1 Like

Good to know, thanks. All the website server stuff is a complete mystery to us mere mortals :wink:

Since you seem knowledgeable, how hard is it to turn these red table items into green i.e. for website maintainer? →



  • Generating the headers should be quite easy, depending on the granularity. I’d suggest creating one for each application (wiki, blog, forum, phabricator) starting with a restrictive report-only version and when no more reports come in enforcing it.
  • Making the headers more effective (i.e. not using unsafe options) is a bit harder as this would require some code changes. Currently you are using some inline-JS and inline-CSS which would be ideally moved to a file or at least get a hash or nonce.
  • And you are using some style-Attributes which are can’t get a hash or nonce and thus can be used only with unsafe-inline, these should be replaced by css classes if possible
  • The CSP header might has to be modified if an application changes

I haven’t used PK or CA pinning yet, so the following is just as far as i know.

PK pinning:

  • Requires two certificates using different public keys in case one has to be revoked
  • It’s dangerous! Start with short time periods and test both certificates
  • If you get a new public key you have to update your header soon enough to include it during a transitional period
  • After testing you shouldn’t have to touch it until you plan to get a new key pair

CA pinning:

  • Requires two certificates from different CAs in case one has to be revoked
  • Less dangerous, but still start with short time periods and test both certificates
  • If you change your CA or they get a new public key you have to update your header soon enough to include it during a transitional period
  • After testing you shouldn’t have to touch it until you change your CA or your CA gets a new key pair to sign certificates
1 Like

Sorry, I don’t understand your question. Could you please provide more details? Maybe you mean this?




Generally, a CSP would be great!

We don’t develop any web apps. We are using Libre Software. Mediawiki (wiki), wordpress (blog), phabricator (issue tracker) and discourse (forum). We don’t have resources to make changes on the code level. But if you wish, please feel very free to report any such issues against these projects. Because then these fixes would flow down as we update these web apps.

Which makes this require constant maintenance.

Perhaps mediawiki, wordpress, phabricator and/or discourse are providing boiler plate CSPs we just can copy/paste and are free to use? If not, could you make a feature request against these projects please?

For MediaWiki it’s an open ticket: ⚓ T135963 Add support for Content-Security-Policy (CSP) headers in MediaWiki

For Phabricator it’s an open ticket: ⚓ T4340 Implement Content-Security-Policy and Strict-Transport-Security headers

For discourse I could only find a from post: https://meta.discourse.org/t/how-to-configure-content-security-policy/53308

For wordpress there is an old (6 years) plugin which allows automatic creation of the CSP header: https://people-mozilla.org/~bsterne/content-security-policy/wordpress.html
and a newer one which seems to be manual: WP Content Security Plugin – WordPress-Plugin | WordPress.org Deutsch

I could make some CSPs which allows the use unsafe-inline code if required until those apps are compatible. This would at least prevent an attacker from embedding external sources.

You could setup a small script which logs policy violations to fix them as they occur (example).

CSP for *.whonix.org/* (in case you want to manage just one CSP for everything):

default-src 'none';
script-src  'self' 'unsafe-inline' 'unsafe-eval';
style-src   'self' 'unsafe-inline';
img-src     * data:;
font-src    'self';
connect-src 'self'

Other CSPs I have created during my tests:

CSP for forums.whonix.org/* (the Onebox feature embeds external images from various locations):

default-src 'none';
script-src  'self' 'unsafe-inline' 'unsafe-eval';
style-src   'self' 'unsafe-inline';
img-src     *;
font-src    'self';
connect-src 'self'

CSP for phabricator.whonix.org/*:

default-src 'none';
script-src  'self' 'unsafe-inline';
style-src   'self' 'unsafe-inline';
img-src     data: 'self';
font-src    'self';
connect-src 'self'

CSP for www.whonix.org/blog/* (profile images from the forum are embedded using HTTP):

default-src 'none';
script-src  'self' 'unsafe-inline';
style-src   'self' 'unsafe-inline';
img-src     data: https://forums.whonix.org https://forums.whonix.org 'self'

CSP for www.whonix.org/wiki/* (one image was requested from wikimedia):

default-src 'none';
script-src  'self' 'unsafe-inline' 'unsafe-eval';
style-src   'self' 'unsafe-inline';
img-src     https://upload.wikimedia.org 'self';
font-src    'self'

CSP for https://www.whonix.org/ (has an inline onclick event to hide the donation message):

default-src 'none';
script-src  'unsafe-inline';
style-src   'self' 'unsafe-inline';
img-src     'self'

CSP for https://www.whonix.org/download/:

default-src 'none';
style-src   'self';
img-src     'self'

CSP for www.whonix.org/cgi-bin/mailman/* (has an inline script):

default-src 'none';
script-src  'unsafe-inline';
img-src     'self'

CSP for www.whonix.org/pipermail/* (has an inline style):

default-src 'none';
style-src   'unsafe-inline';
img-src     'self'

Note: I’d recommend setting up an endpoint for CSP violation reports for debugging purposes in case something needs more permissions.


It’s worth noting that unsafe-inline and unsafe-eval essentially make the CSP worthless - this still allows XSS to fire, since an XSS payload would be “inline”. I don’t have the time, knowledge, or ability to go through the myriad of software this website runs to “fix” their inline scripts.

If/when upstream projects (phabricator, mediawiki) do away with inline scripts, I would be definitely willing to take another look at this.

I have to say thanks for your hard work in making the policies, as well as your concern about our security posture. I feel like, for the time being, we have a sane balance between securing ourselves (HSTS, x-xss-protection) while avoiding potentially DoSing ourselves by setting things up wrong (HPKP, to a lesser extent CSP).

1 Like

Yes, those CSPs won’t effectively stop an XSS attack, but still limit what an attacker can do and make it harder to do something useful if an XSS injection succeeds, for example interactive communication (connect-src) with remote servers is still prevented by the CSP.

The first CSP I proposed is safe enough to not DoS yourself. Even if a future application requires more permissions (for example embedding a flash object) most features will still work as expected and should remain usable, also you get a report as soon as it happens and a fix would be pretty easy (just add the missing permission, reload, done).

You could try the CSP in report-only mode for a month or so and see if it would block anything that shouldn’t be blocked or change the default-src to 'self' or even *.whonix.org instead of 'none' which would permit applications to do anything as long as its on the same host or hosted on a Whonix subdomain (unless a more specific directive is given) if you fear DoSsing yourself.


Hi @Hexagon,

I’m currently looking at the CSP headers (new sysadmin).

Your examples are really useful and I’ll be using those as a basis with which to achieve it.

I agree with @fortasse’s reservations, but I also agree with you that having a CSP with unsafe-inline is better than none at all for other reasons.

I was just wondering what was the purpose behind unsafe-eval? Did you find cases on Discourse or the Wiki where that was actually required?

In the time since this ticket, Phabricator actually implemented a CSP, and since we upgraded Phabricator recently, we have pulled that in. ⚓ T135963 Add support for Content-Security-Policy (CSP) headers in MediaWiki

It looks like MediaWiki merged in code for it recently too (March 2018), albeit they think it may break many gadgets/extensions so we’ll have to tread carefully.

Discourse is a ways off, they don’t consider it a priority/have no resources for it. Same link as you found.

I’ll be looking at adding individual CSP headers to the various other areas (ignoring /blog since that’s been sunset in favour of Discourse) soon.

Currently fighting with my own site’s CSP when under .onion, despite the .onion host being whitelisted! Grrr…


CSPs now deployed:


Whatever you are doing is working as the server is running much better than the old days. Seems upgrades etc are beneficial, as .onion is not super flaky anymore.


4 posts were split to a new topic: fix extra white space on all PDF embedded links

Until now whonix considered B, And according to these sites:

Issue is:

script-src ‘self’ https://*.whonix.org ‘unsafe-inline’ ‘unsafe-eval’

style-src ‘self’ https://*.whonix.org ‘unsafe-inline’

1 Like

CSP issue. Not reasonable to work on this. Reasoning here:

Applicable chapters:


CSP simplification.

Reason for simplification: Website breaks in corner cases and the more complex CSP also does not provide higher security. It’s just more complex. Website and Server Tests scores are unchanged.


content-security-policy: default-src ‘none’; connect-src ‘self’; script-src ‘self’ https://.whonix.org ‘unsafe-inline’ ‘unsafe-eval’; style-src ‘self’ https://.whonix.org ‘unsafe-inline’; img-src ‘self’ data: https://.whonix.org; font-src ‘self’ https://.whonix.org;


content-security-policy: default-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’;