Improve default Content-Security-Policy value

[LeoColomb]

See h5bp/server-configs-apache#181

[quantumpacket]

In all honesty from a security perspective the CSP should be deny everything for all directives by default. Then whitelist per directive as needed. That's the most secure and least shoot your security in the foot scenario by accident.

[LeoColomb]

Thanks for your comment, @quantumpacket! 👍
What values do you suggest?

[quantumpacket]

@LeoColomb these would be more restrictive baseline CSPs templates. This way the application has a secure starting point, and an admin can then loosen it if needed.

CSP2:

Content-Security-Policy: default-src 'none'; frame-ancestors 'none'; form-action 'none'; upgrade-insecure-requests; require-sri-for script style; sandbox; base-uri 'none'

CSP3: (some experimental directives, browser support will vary)

Content-Security-Policy: default-src 'none'; frame-ancestors 'none'; form-action 'none'; upgrade-insecure-requests; block-all-mixed-content; disown-opener; require-sri-for script style; sandbox; base-uri 'none'; navigate-to: 'none';

[LeoColomb]

Thanks @quantumpacket.
See answers here: h5bp/server-configs-apache#181 (comment)
You can join the discussion there. 🙂

[Malvoz]

require-sri-for <style|script> tells the browser that the document must provide SRI metadata for all resources of that type (style and/or script). This may break functionality as not all eligible resource responds with CORS headers.

Unfortunately there is currently no way (maybe in the future) for this CSP directive to provide any granular control by saying "hey! require SRI for only this one script". It's all or nothing, and I think this is why the directive has seen limited usage amongst developers. (You can still opt-in for SRI matching by setting the integrity attribute to the desired <script> or <link> elements).

So I'd say no to require-sri-for as a default.

The navigate-to CSP spec description says:

[...] an enforcement on what navigations this document initiates not on what this document is allowed to navigate to.

This is a tad bit confusing but it seems to suggest that If I (abc.xyz) would set navigate-to https://example.com then if a user clicks <a href="https://not.example.com"> then https://not.example.com is only allowed to navigate to https://example.com?

Personally I don't think that's a good default because I'd imagine the majority of website owners do not care for, or want that type of restriction (maybe something an advertiser would want to use). I'd even go as far as to say that such a behavior (navigation blocking) doesn't match users expectations of how the web works.

The directive is under development still:
https://www.chromestatus.com/feature/6457580339593216
https://bugzilla.mozilla.org/show_bug.cgi?id=1529068

@quantumpacket

I've addressed my approach to most of the other directives that you mentioned in h5bp/server-configs-apache#181 (comment).