This is from an external blog. You can view the original, or subscribe, here.
The Content Security Policy specification, a technology to prevent cross-site scripting attacks, has advanced from Working Draft to Candidate Recommendation. Which is a good thing, but unfortunately has the side effect that bookmarklets are going to stop executing on any web page that implements it.
What’s a bookmarklet?
the code can, if it wants, load code from any other site into the current pages’ DOM, and execute that instead.
One bookmarklet I use is Instapaper which submits the current page to your ‘read later’ list. And there are loads of bookmarklets to assist web designers.
What’s Content Security Policy?
For example, if I’ve got a bit of custom form validation code, then the current domain will need to be whitelisted, and if I’m running Google Analytics, I’ll trust Google too. To trust both locations the appropriate header would look like this:
Content-Security-Policy: script-src 'self' http:
But CSP does other things!
If you include a Content Security Policy header in your page, you’re also saying that the browser should adhere to a few additional security rules:
- Inline scripts are banned (inside <script> tags in the page) to prevent injection attacks
- ‘eval’ is ignored, and that includes its use within setTimeout/setInterval
That last one is important because that’s what bookmarklets do. Additionally, if the bookmarklet loads an external script to run, that won’t work.
Current browser support
Firefox 4 and Chrome 16. Although, they are using X-Content-Security-Policy and X-WebKit-CSP respectively at the moment.
Current web uses
Twitter claim they’ve rolled it out on their mobile site, but looking at the headers, I can’t see any evidence of it. I found this site which is sending the X-Content-Security-Policy header (the Firefox one) and I can confirm my Instagram bookmarklet is definitely dead there.