Support 'strict-dynamic' by default

[mikispag]

It would be really cool if you could add support for 'strict-dynamic' (W3C) by default.

Google is offering Google Patch Rewards for integrating CSP in popular frameworks and facilitating adoption (as you already did, so please apply!).

The most recent research on CSP demonstrated that the whitelist-based approach is intrinsically flawed for XSS mitigation, and that a nonce/hash + 'strict-dynamic' policy, similar to the ones already served by important Google products, is in the quasi-totality of cases the only working solution.

There are a lot of misconceptions about CSP, and getting rid of things that are proven not to work is good - the worst thing you can have is a false sense of security.

If you could also add a link to the CSP Evaluator to your README, to let users evaluate the quality of their policy, it would be awesome.

Please do not hesitate to get back to me if you need any additional information or have doubts.

More resources

• https://csp.withgoogle.com
• https://csp.withgoogle.com/docs/strict-csp.html
• https://csp-evaluator.withgoogle.com
• https://www.google.com/about/appsecurity/patch-rewards/

[aidantwoods]

@mikispag

Google is offering Google Patch Rewards for integrating CSP in popular frameworks and facilitating adoption (as you already did, so please apply!).

I'll definitely take a look at this, thanks for the link! Is it worth applying now, or should I wait until I have a proper full version done? (shouldn't be long away!)

The most recent research on CSP demonstrated that the whitelist-based approach is intrinsically flawed for XSS mitigation, and that a nonce/hash + 'strict-dynamic' policy, similar to the ones already served by important Google products, is in the quasi-totality of cases the only working solution.

Don't have to convince me of that! 😉

RE making it default behaviour – at the moment my approach towards pushing good settings is having SecureHeaders 'complain' until those settings are configured ('sanely').

With that in mind, adding a check for 'strict-dynamic' in the CSP sanity check would be most inline with SecureHeaders' current behaviour (useful but hopefully non intrusive defaults, and compain until things are ideal).

I.e. so that 'strict-dynamic' is encouraged (if a source list is present) similarly to these being discouraged https://github.com/aidantwoods/SecureHeaders#another-example

the worst thing you can have is a false sense of security

This comment is along the lines of why I wouldn't want to specify a default CSP for SecureHeaders – it would either break things, or be overly broad and useless. Though I can see a good middle ground where a dev could opt-in to some defaults that are 'better, but may need configuring to make your application work'.

Alternatively, I could auto-add 'strict-dynamic' if a nonce is in the source list, but not otherwise. (though automatic behaviour like this needs to be balanced imo – if it's too unintuative, it may discourage use of SecureHeaders all together if devs find it unpredictable. Especially if devs are testing in non CSP3 compliant browsers – they wouldn't even notice it).

If you could also add a link to the CSP Evaluator to your README, to let users evaluate the quality of their policy, it would be awesome.

I'll definately add a link to that – it's a great resource. It may make sense to add the link into warnings triggered by the CSP sanity check too, just so devs see it if they're writing CSPs that raise obvious flags.

[aidantwoods]

Okay, so I've added ->strict_mode() which bundles 'strict-dynamic' in along with HSTS with long duration and preload criteria.

SecureHeaders will honour user set HSTS preferences if set though (or if they've asked to remove the HSTS header via ->remove_header()).

I'll probably think of a few other interesting things to stick in 'strict-mode', could possibly make it add a few extensions to safe-mode, e.g. wildcards picked up in certain directives during CSP validation are auto-removed.

[mikispag]

Very nice, thanks!

Do you enforce the presence of at least one nonce or hash together with 'strict-dynamic'? Otherwise it will just break the application...

[aidantwoods]

I was thinking more along the lines of spitting out an E_USER_WARNING if no nonces/hashes are added. Since ->strict_mode() is opt-in, IMO it's valuable to show devs what settings they should use in headers, and encourage them to change their application around those (rather than hoping they happen to generate a nonce/hash to benefit).

Let me know if that makes sense? Happy to reconsider it if I'm making a silly decision here

[mikispag]

I think we should not add 'strict-dynamic' if there is no nonce or hash, because it would just break the application. So we should probably enforce the use of nonces or hashes in strict mode, together with 'strict-dynamic'. What do you think?

[aidantwoods]

Summary of that change:

If strict mode is enabled, SecureHeaders will take directive to be either default-src or script-src (whichever is set). If both are set, script-src is used. If directive contains a nonce or hash source value then inject 'strict-dynamic' into the CSP source list for directive, otherwise issue the following:

Warning: Strict Mode is enabled, but couldn't add 'strict-dynamic' into the Content-Security-Policy because no hash or nonce was used.

[mikispag]

Awesome, exactly what I was thinking, thanks!

[aidantwoods]

Great 👍 Let me know if you think of anything else!