Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / web / HTML

The Slow Death of Bookmarklets

5.00/5 (1 vote)
20 Nov 2012CPOL2 min read 29.4K  
The slow death of Bookmarklets

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?

It’s a small piece of JavaScript embedded in a link. That link is then added to your browser’s bookmarks. When it’s clicked, the script is executed. A bookmarklet always takes the form:

JavaScript
javascript:alert("hello");

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?

A W3C specification, call it part of HTML5 if you want to. It’s a collection of new HTTP headers that a page can include to indicate a list of places from which JavaScript should be trusted. Any scripts which do not appear on that whitelist will not be executed, which means the site is well protected against XSS attacks (when the users have supported browsers).

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://www.google-analytics.com

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
  • The JavaScript: link format is ignored.

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.

This post focuses on the JavaScript side of the CSP specification, but it can also apply to any other type of resource (fonts, images, etc.). Have a look at the HTMLRocks page for more information!

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)