🌐 Website Issue | CSP (Security) Improvements #801

New Issue

jonah · 2019-03-31T14:29:28Z

jonah commented

2019-03-31 14:29:28 +00:00

Description

We've re-enabled (#303) the Content Security Policy header on the site in the server settings with the following settings:

default-src 'self';
script-src 'self' 'sha256-hUlNBcv+Trdlc6g1XjFLvylOaIBXEqPNHfXANcRQ0SA=' 'sha256-r2NDpHpWNsnqUZmiRtaHj7dBgoEHP37PPZQvDvILaTQ=' https://stats.privacytools.io;
style-src 'self' 'unsafe-inline';
img-src 'self' data: https://*.privacytools.io;
object-src 'none';
frame-src https://stats.privacytools.io;

This is generally a good configuration, we now pass Mozilla Observatory's Test, but there are some improvements that could be made:

Ideally we would remove 'unsafe-inline' from style-src to only allow CSS loaded from trusted pages rather than in the HTML itself. We can't do this however because we have some inline style tags that would break.
- All style HTML tags should be moved to their own file. We should probably make a custom.css for this purpose, or just throw new classes in assets/css/style.scss.
We should also strive to have default-src set to 'none'. This is probably doable right now, but more testing needs to be done.
- Ensure everything we use is accounted for in the header.
- Ensure there's no inline rendering that would break.
The hamburger icon on the mobile layout in the navbar is the reason I needed to include data: as an image source. Unfortunately that's relatively unsafe.
- Is it possible to switch to Font Awesome for that icon as well, instead of a data: blob in the CSS?
I needed to include 'sha256-hUlNBcv+Trdlc6g1XjFLvylOaIBXEqPNHfXANcRQ0SA=' 'sha256-r2NDpHpWNsnqUZmiRtaHj7dBgoEHP37PPZQvDvILaTQ=' to allow two of our inline Javascript scripts to run, as an alternative to allowing 'unsafe-inline' to run Javascript. This is fine but it means we cannot change these two scripts without modifying the server settings (because their hashes are hard coded in the header):

This is probably no big deal, but a better solution would be to:
- Move them to their own files (separate .js files) if possible. (#396)

767be34f55/_includes/scripts.html (L5-L15)

767be34f55/_includes/scripts.html (L24-L36)

## Description We've re-enabled (#303) the Content Security Policy header on the site in the server settings with the following settings: ``` default-src 'self'; script-src 'self' 'sha256-hUlNBcv+Trdlc6g1XjFLvylOaIBXEqPNHfXANcRQ0SA=' 'sha256-r2NDpHpWNsnqUZmiRtaHj7dBgoEHP37PPZQvDvILaTQ=' https://stats.privacytools.io; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://*.privacytools.io; object-src 'none'; frame-src https://stats.privacytools.io; ``` This is generally a good configuration, we now pass [Mozilla Observatory's Test](https://observatory.mozilla.org/analyze/www.privacytools.io), but there are some improvements that could be made: 1. Ideally we would remove `'unsafe-inline'` from `style-src` to only allow CSS loaded from trusted pages rather than in the HTML itself. We can't do this however because we have some inline style tags that would break. - [ ] All style HTML tags should be moved to their own file. We should probably make a custom.css for this purpose, or just throw new classes in `assets/css/style.scss`. 2. We should also strive to have `default-src` set to `'none'`. This is probably doable right now, but more testing needs to be done. - [x] Ensure [everything](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#Directives) we use is accounted for in the header. - [x] Ensure there's no inline rendering that would break. 3. The hamburger icon on the mobile layout in the navbar is the reason I needed to include `data:` as an image source. Unfortunately that's relatively unsafe. - [ ] Is it possible to switch to Font Awesome for that icon as well, instead of a data: blob in the CSS? 4. I needed to include `'sha256-hUlNBcv+Trdlc6g1XjFLvylOaIBXEqPNHfXANcRQ0SA=' 'sha256-r2NDpHpWNsnqUZmiRtaHj7dBgoEHP37PPZQvDvILaTQ='` to allow two of our inline Javascript scripts to run, as an alternative to allowing `'unsafe-inline'` to run Javascript. This is *fine* but it means **we cannot change these two scripts** without modifying the server settings (because their hashes are hard coded in the header): This is *probably* no big deal, but a better solution would be to: - [ ] Move them to their own files (separate .js files) if possible. (#396) https://github.com/privacytoolsIO/privacytools.io/blob/767be34f55a927c56b12c949034b0ad18b767dbb/_includes/scripts.html#L5-L15 https://github.com/privacytoolsIO/privacytools.io/blob/767be34f55a927c56b12c949034b0ad18b767dbb/_includes/scripts.html#L24-L36

jonah commented

2019-03-31 14:36:00 +00:00

Adding font-src 'self'; manifest-src 'self'; allows us to set default-src 'none'; so I've gone ahead and done that. Since we've defined pretty much everything else now there shouldn't be any future drawbacks to having it set to 'none'.

Adding `font-src 'self'; manifest-src 'self';` allows us to set `default-src 'none';` so I've gone ahead and done that. Since we've defined pretty much everything else now there shouldn't be any future drawbacks to having it set to `'none'`.

blacklight447 commented

2019-08-28 18:10:56 +00:00

(Migrated from github.com)

is this sill an issue @jonah ?

blacklight447 commented

2019-09-05 12:47:30 +00:00

(Migrated from github.com)

Bump @jonaharagon

Zenithium commented

2020-03-07 17:34:50 +00:00

(Migrated from github.com)

What happened to this? @JonahAragon

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#801