Nginx and Content-Security-Policy
((I've recently gone from shared hosting to cloud hosting I never had to deal with such server issues…and been working at this for a week now.))
The website is: http://tuxug.com/index.php
I'm building a forum and trying to get Google Fonts to work (I've checked with CSP validator website and it passes and the security headers website I've gotten an "A" rating) and also trying to include a robohash nice little avatar for guests and members to use.
I seem to be running into an issue with CSP on both Firefox and Chromium and I'm getting duplicate headers as well.
I've only got one single app running through my nginx and I've been editing the headers in sites-enabled directory and I just can't seem to source or debug this.
Could anyone help me please? I don't know of any other place to ask to trouble shoot.
My thanks!
5 Replies
A page that highlights all the issues would be: http://tuxug.com/topic-view.php?i=1
In developer console you can see all the CSP issues I have been trying to debug and fix.
Thank you for your time.
A copy of the response headers:
TTP/1.1 200 OK
Server: nginx
Date: Wed, 09 Dec 2020 22:46:09 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: close
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Permissions-Policy: accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()
X-Frame-Options: SAMEORIGIN
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self' robohash.org data: gap: ssl.gstatic.com;object-src 'self';font-src 'self' fonts.gstatic.com;style-src 'self' fonts.googleapis.com;script-src 'self' robohash.org;base-uri 'none'
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: default-src 'self';script-src 'self' 'unsafe-eval' 'unsafe-inline';style-src 'self' 'unsafe-inline'
Content-Language: en
Cache-Control: no-cache, must-revalidate, stale-while-revalidate, max-age=0, private, no-transform
Pragma: no-cache
Expires: 0
A copy of the errors:
topic-view.php:4 Refused to load the stylesheet 'http://fonts.googleapis.com/css?family=Ubuntu%7CPT+Serif' because it violates the following Content Security Policy directive: "style-src 'self' 'unsafe-inline'". Note that 'style-src-elem' was not explicitly set, so 'style-src' is used as a fallback.
topic-view.php:1 Refused to load the image 'http://robohash.org/0ba49a80e808a78a5a40004f5b59a9ae?set=set4&size=60x60' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.
topic-view.php:1 Refused to load the image 'http://robohash.org/52c668584d31cdbd4f9277b18b835b5d?set=set4&size=60x60' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.
topic-view.php:1 Refused to load the image 'http://robohash.org/52c668584d31cdbd4f9277b18b835b5d?set=set4&size=60x60' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.
topic-view.php:1 Refused to load the image 'http://robohash.org/0ba49a80e808a78a5a40004f5b59a9ae?set=set4&size=60x60' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.
Note that I have the CSP written correctly and verified by two trusted people so it should work.
Someone has told me it could be my own security settings because the google fonts are working for them (which means they have no protections for CSP.)
But I'm using purposely using a default chromium and firefox so that I can hopefully alleviate any issues any visitors may have. :/
EDIT: …Bueller? :(
Seriously? Nothing? Sigh. I am closing my account now. Something like this is just bonkers that it can just shut you down outside your influence because of the browser. (If anyone's wondering, imgur and gravatar both won't load on a default firefox or chromium with these same CSP errors as I have.)
andrewm
Linode Staff
I'm sorry that you decided to close your account before you were able to resolve this matter. I looked over this with a few of my colleagues -- while we're not experts on CSP, and the site doesn't appear to be running anymore, we wanted to offer the following suggestions:
It appears that your website was using regular plaintext HTTP based on the URLs you provided. I don't see anything in the CSP specification which prevents you from using it with plaintext HTTP, but this may be triggering a default rejection at the browser level.
To alleviate this concern, I would recommend installing an HTTPS certificate for your Linode. This will also have the benefit of enhancing visitor trust and improving SEO ranking. You may read more about how to do this here:
If you are not using Ubuntu 18.04, you may use the platform selector at https://certbot.eff.org/ for exact instructions on your particular setup.
Your output appears to be showing two separate CSP policies:
Content-Security-Policy: default-src 'self' robohash.org data: gap: ssl.gstatic.com;object-src 'self';font-src 'self' fonts.gstatic.com;style-src 'self' fonts.googleapis.com;script-src 'self' robohash.org;base-uri 'none'and
Content-Security-Policy: default-src 'self';script-src 'self' 'unsafe-eval' 'unsafe-inline';style-src 'self' 'unsafe-inline'The debug output you have shown us suggests that your test environment is only checking the external resources against the second CSP policy, then returning a reject. However, it is also possible that both policies are being taken into consideration, but the stricter second policy is overruling the first policy.
My impression here is that you are defining your CSP policy twice within your Nginx configuration. I would recommend reviewing your Nginx configuration to see if you can identify multiple CSP definitions, particularly focusing on the
server {}blocks.If you are still unable to troubleshoot this issue with the suggestions above, you may want to see if you can pre-load these assets onto your website server-side. At that point, you may either rely upon the
default-src 'self'CSP clause to allow the transmission of the content to your visitors, or simply remove your CSP policy altogether.
My colleagues and I were able to retrieve the following pages providing some background information and similar circumstances:
- https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
- https://content-security-policy.com/
- https://stackoverflow.com/questions/31211359/refused-to-load-the-script-because-it-violates-the-following-content-security-po
- https://csper.io/blog/csp-violates-the-content-security-policy-directive
I hope that you eventually decide to try setting up this website again on our platform, but even so, I hope you find this information helpful as a future resource. Please let us know if you have any other questions or concerns for us.
That is weird you blame Linode staff for your Nginx headers error. That is your choice to install the header or not?
I think your Wordpress or CMS is generating the same CSP header so it conflicts with Nginx.
You should use CSP in the CMS only to make it easier to adjust. And you forgot to install SSL too that is much more important…