I already blogged about my problems with Disqus and the Content Security Policy header twice, but recent changes in Disqus made me revisit the whole topic.
Burak Yiğit Kaya, developer at Disqus, made a few changes we discussed about a month ago, that would improve the coexistence of Disqus and CSP on a website. While both could be run together before, these improvements transform the from a dirtily hacked state into a real dream team.
Back when Burak first contacted me, we came up with a few ideas on how to improve Disqus to work better with CSP, such as
- remove all inline CSS
- remove all inline Images (data:base64=…)
- Unify all ressources under two distinct domains,
- a.disquscdn.com for static content (cookieless domain)
- disqus.com for dynamic content
I’m happy to report that all of the above improvements have now been implemented, which I think is awesome news. There is one more thing on the to-do list, which Burak said, he has yet to solve.
- move the beacon pixel at referrer.disqus.com to the other domain.
The last one isn’t really that important, but it removes one domain from the policy, which is always a good thing as it keeps the ruleset shorter and thus easier to maintain. But why is it so important to have a good integration with CSP? If the hack worked, why should Disqus care about a proper fix and more importantly – why should they spend resources on this?
For one, supporting security features like CSP, and actually working together with people who have questions, concerns or ideas for improvement on a products security, shows that a company actually cares. Of course, that’s what every company always claims – especially in the light of any recent security fails – but here we have actual proof.
There is more to it then that though. Up until now, getting CSP and Disqus on the same page required to either block certain requests or allow them via unsafe CSP options. I’m talking about things like inline CSS, images embedded as base64 encoded strings and alternate domains that serve nice-to-have content such as icons. Of course diminishing the security of our CSP is not really an option, but blocking sources in favor of keeping
unsafe-* options disabled is also a bad choice, as it results in your CSP logs getting spammed with violations. You do log your violations, don’t you?
The CSP logs are a great way of receiving notifications as soon as someone stumbles across a potential XSS vulnerability and starts tinkering with it. If code is injected successfully, the CSP will block it and create a new entry in the log files. All you need to do is setup CSP and make sure that normal browsing of your site doesn’t create any violations. Once your site is clean, setup some form of notification for anything that hits the logs.
Of course that’s only an option when your site is actually clean and not constantly throwing violation errors in your face.
Finally, Burak told me that he wanted to write a howto on using Disqus with CSP, which is great.
If you’re curious as how my CSP looks, just take a look at my HTTP headers with
curl -I https://www.hashtagsecurity.com
This should give you the full ruleset, among other headers I’ve set.
If you have questions about CSP, use the comments, contact me on Twitter, or check out my CSP talk.