Content security policy

I put my new site through an online security check. Several problems were found.

1. No content security policy.
   I found a post in this Forum dated 2015 about this. But nothing more recent. Is this something that I need to deal with in the Apache config, or in Grav?

Grav seems to have a lot of security features already, so is a security policy neeeded?

1. Strict transport security. In general, I wonder if it is necessary to deal with this warning. Second, it seems to be an HTTP header setting. How should this best be done with Grav?

2. vulnerabilities due to Jquery 2.2.4 (another post). Eliminating all Jquery 2.1 dependencies seems to be quite laborious and associated with the Theme I chose.

So I looked into this further.

It seems the best place to handle HTTP header is in the server configuration. I use Apache 2.4, but searching on line yields similar for NGINX etc.

1. Strict Transport

   TXTCopy

   Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
   

   to the config file for the HTTPS !!!! part of the domain (adding to the HTTP part did not work for me).

2. Strict Policy
   In principle the same, but setting the policy is more difficult as GRAV and Themes source files from CDNs.

As an example, because I have PayPal buttons and a map from Thunderforest, but do NOT assume this will work for yourself, I have

Header set Content-Security-Policy "default-src 'self' *.paypal.com *.unpkg.com *.thunderforest.com;"

Enabling and setting Security Headers is a general website security topic and as far as I can tell there's nothing Grav specific about it. I did learn a lot by reading Scott Helme's blog articles. Using Apache I had a go with adding security headers to the default Grav .htaccess file.

The site securityheaders.com is a great help to see how you're security is improving as you add more headers. Unfortunately the site I was working on didn't go live but I remember the only real issue I had was with trying to run Grav without any inline Javascript.

Thanks for the feedback.

Actually, I have had to revert the content policy header. As you say, lots of little things stopped working.

I have not worked out all the wrinkles. For example, various plugins do not load correctly, even though I seem to have specified the source correctly.

And, as you say, inline javascript has to be eliminated.

Hi!

I am struggling with the CSP header as well, have you gotten any more success?

@iamerwin
Unfortunately not. I placed a header in the Apache file, but the site broke. So I had to comment it out.

There are multiple problems because of the use of inline javascript, which is now considered to be a security issue. It was not always considered so.

Inline Javascript is still possible or allowed by signing it, see https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html#refactoring-inline-code

Multiple inline scripts may be specified as well, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src

The problem is identifying where all the inline JS exists, and then dealing with it.

The template I chose seems to have a number of places with inline JS.

I do not know a quick / sytematic way of tracking the JS code down. That means going through the source code by hand.

One way could be to have a plugin look for the JS code in the HTML Grav outputs in the onOutputGenerated event. And then maybe pass each JS code block on to a shell script which calculates the hashes and updates the .htaccess file?

a) This seems to be a solution for Apache, but what about NGINX et al.
b) The Admin plugin has a REPORT section. It handles YAML linting. What about Security warnings?

Ad a) Personally I think this is beyond the core business of a CMS. Besides that it would be very hard to create a generic solution for all combinations of server operating system and web server make being used. Not even taking into account which version of each and any local user permissions on that server.
Ad b) Do you mean the Grav Security Check section on the Reports tab under Tools - Reports? Yes that would be a logical place.

Re (a) I was implying a generic solution would be going too far.
Re (b) Yes I did mean the Reports tap under Tools.

In fact it seems to me that to keep GRAV at the bleeding edge, providing information about security issues and where they occur would be a good place to develop.

Reporting on issues, rather than doing anything about them, puts the burden on the developer of an instance of Grav, not on the developer of Grav.