Possibility to block all javascript: URLs

[Sjord]

I would like to request a new feature for the CSP: the possibility to block or restrict javascript: URLs, without blocking other scripts.

• Legitimate use of javascript: URLs is relatively rare. Some applications don't use it at all, and it's possible to get similar behavior with event handlers.
• In applications that automatically output encode all variables, this is one of the few paths to XSS.

In applications that don't use javascript: URLs, it would be easy to disable it altogether without compatibility issues. Injection of URLs is often the only path to XSS in applications that perform proper output encoding, and this would disable that attack vector.

[dveditz]

That's a hard "no" from me personally.

If the application can 100% correctly "encode all variables" and prevent XSS, why can't it correctly filter out links that don't match /^http(s)?:/.test(url) ? Either you're strictly limiting the ability of injections to run script or you're not.

One work-around—if you're really really confident in your ability to sanitize inline script and prevent any injections—is to hardcode a nonce in your policy and then just always stick that in every <script>. Same effect as what you're asking

[norman-cmt]

@dveditz content security policy is for additional protection in case is something is not 100% properly implemented in the web application, so I don't think expecting a proper implementation is a good answer to this.

Adding static nonces is a good solution, but to implement this, users needs to modify the source code of the website, and the headers are sometimes manipulated by web server configurations and/or WAF. You need access to all those configurations to implement this protection, and in a lot of hosted environments you can't do this (for example in free web-hosting services)

In contrast, adding this header can be done out-of-box by the WAF or in the web server configuration, so server admins can implement this protection without modifying the website source code.

I think that's good, and comes with zero drawbacks.

[awwright]

Of course you filter URLs by scheme, but I'm not sure how that means a CSP is a bad idea. Almost certainly you want to deploy both strategies for defense in depth, not one or the other.

If the application can 100% correctly "encode all variables" and prevent XSS
Either you're strictly limiting the ability of injections to run script or you're not.

Also these assumptions are not necessarily true. I understand the whole reason for CSP is that applications don't prevent XSS "100% correctly"