CSP has a bunch of features, but the core value proposition (in my view) is that web applications can whitelist where their scripts come from. The main drawback of this approach is that authors need to remove all inline script from their web application because the browser doesn't know whether an inline script is part of the application or whether it was injected as part of a cross-site scripting (XSS) attack.
Initially, I was skeptical about CSP for two reasons:
- CSP has a bunch of functionality unrelated to mitigating XSS, which makes the feature more complicated than necessary. Because I'm a big believer in minimal viable products, my initial reaction was to remove all the extra functionality and focus on the core use case for the first iteration.
- I was worried that removing all the inline scripts from a web application would be too hard because web applications use inline scripts frequently. Joel Weinberger, Dawn Song, and I even wrote a paper exploring that issue.
Thanks to some great work by Thomas Sepez, Chrome now uses CSP in the vast majority its HTML-based user interfaces. Over the years, there has been a steady trickle of XSS vulnerabilities in these interfaces, which is problematic because these interfaces (such as the browser's settings interface) have powerful privileges. Now that Chrome uses CSP extensively, we can be confident that we've mitigated this entire class of vulnerabilities.
My perspective on CSP now is that it makes a serious dent in one of the biggest problems in web security. It's definitely not a silver bullet (nothing ever is), but we should invest in CSP because we should be working on the big problems. If we're not willing to dream big, we should just pack up our tent and go home.
I just found your blog, and I already find it very interesting and useful. Keep blogging. I'll keep reading.
ReplyDelete