Content-Security-Policy

[dvershinin]

Allow specifying CSP header using "free-form" string.
There is no one-suits everyone value.
The module should support setting it anyway, as this will eliminate having to have header-more module completely, in most setups.

[jamesmacwhite]

I would personally not set a Content-Security-Policy header in this module. The reason being is many CSP headers are tailored to the specific app, some services may provide their own policy in the code base without having to set it in NGINX. Some can be stricter than others as well while others may need unsafe-inline. You won't be able to set a suitable CSP policy that fits every scenario, or if you do, you'll like downgrade the security of CSP for some applications, if they can be stricter than others but you'll essentially bring others down to the lowest level.

The simplicity of having security_headers on in the http block is nice, but I don't think it's feasible for CSP. I think it is acceptable that the CSP header has to be added per virtualhost or even location block in some cases. It is the best for security of that service/application.

You could add documentation on the header in the README.md, but I think this module shouldn't add the header itself. Even with a default value, it's going to cause more problems than it solves I think.

[nisbet-hubbard]

The app-specific requirement is definitely compatible with a security_headers_csp that defaults to off and can be set per server context.

Since this module is intended to be plug-and-play, an A+ grade CSP (ie allowing unsafe-inline in style-src) should give the best out-of-box experience for the majority of users: https://scotthelme.co.uk/a-balanced-approach-new-security-headers-grading-criteria/

Advanced users can always leave it off and tweak their CSP manually without affecting the rest of the module, or only put the directive in server contexts that don’t already have a CSP via the application.