Add support for Content Security Policy

Issue Summary

Content Security Policy (CSP) is a modern browser security feature that affords a site a considerable amount of protection against content injection attacks, mixed-content, data exfiltration and more. Deploying CSP can be difficult but with the addition of nonce support in CSP 2, Ghost could now make the deployment of CSP surprisingly easy.

Backwards compatibility shouldn't be major concern as there is a graceful fallback provided by CSP should a browser not be compliant with a later version of the specification. Take the following policy:

Content-Security-Policy: default-src 'self' 'nonce-abc123' 'unsafe-inline'

An older CSP 1 compliant browser will not understand the nonce value and simply allow the unsafe-inline to take effect and execute inline script on the page. A CSP 2 or CSP 3 compliant browser will support the nonce value which overrides unsafe-inline. In these browsers only inline scripts on the page that bear the nonce=abc123 attribute will be allowed to execute, providing us the full protection of CSP.

### Requirements

Ghost needs to provide a way to inject the nonce value into theme files, something like {{nonce_value}}, and also into scripts or other elements than an author may add to a page in the editor, perhaps using a similar approach.

It would also be nice to be able to edit the CSP header from the Ghost Settings pages. Ghost could inject it’s own CSP as a site is permitted to issue multiple CSP headers, and that would allow a site admin to issue their own CSP alongside for additional features that they may desire, but the single header approach is preferred.

### Benefits

Apart from the obvious benefits of controlling locations that scripts can be loaded from, and which inline scripts may or may not be executed, there are several other features of CSP that could be a great benefit to Ghost users. Here are just a few:

upgrade-insecure-requests

The UIR directive instructs a browser to change any HTTP asset on a page to HTTPS before making the request. This helps to mitigate the risk of mixed-content warnings on a HTTPS site.

form-action

The form-action directive allows a host to control where a form on the site may be submitted to. This is a nice protection to control where the login form can send your Ghost user credentials.

report-uri

CSP reporting is a way to get real-time feedback from your policy by having your visitor’s browser submit reports to you when the CSP is violated. This is a great way to find issues on your site.

[Zokormazo]

the {{ ghost_head }} tag generates an inline <script> block that makes imposible to set any CSP policy that protects the site from XSS attack. Would be possible to avoid that inline js and replace it with a src one or add the possibility to add a custom nonce tag to it?

We could just use clientSecret as nonce= value, so anyone can build a custom CSP policiy with it

[JohnONolan]

If anyone wants to make a new proposal for functional and viable CSP support in Ghost, that’s totally fine and very welcome - you can start with a new issue and a clean slate. (Even better: start the discussion with a PR)