Content Security Policy (CSP) implemented on — the beginning of the end of bookmarklets?

If you’re using Firefox 4, you now gain the additional protection afforded by CSP (Content Security Policy) on

This is a big step forward in terms of protection from any Cross Site Scripting attack – and potentially other browser based attacks – ensuring that even if one occurred, each page could control exactly what pages it can talk to so that there is no possibility of data leakage resulting from the attack.

This has been eye-opening as we’ve implemented it. It has a reporting infrastructure built in so you can see exactly what requests are being blocked. We’ve already seen over a dozen unique bookmarklets caught in our CSP blocking net.

Does this mean the end of bookmarklets? Any site with sensitive data will ultimately implement CSP, making even our own bookmarlet for logging in obsolete. Now is the time to start requesting browsers support overrides to the CSP to keep your favorite bookmarklets working everywhere.

Today, CSP is only deployed on Firefox 4, but the LastPass extension should support it on a number of other browsers in our next release.

We haven’t fully locked down our CSP yet; today we’re allowing every page from to talk to, but soon we’ll lock this down further so that can ONLY talk to, which will be another big step forward.


  • Orion751 says:

    I’m a big fan of bookmarklets because they are cross-platform, then when you want them and not there consuming precious resources when you don’t. Then again, security is more important.

  • Joe Siegrist says:

    There is one underway right now.

  • Anonymous says:

    > “I’m a paying customer and love your product, but I’ll ask what many people have already asked in forums at great length – how about an independent security audit?”

    +1 from another paying customer.

  • Anonymous says:

    I’m a paying customer and love your product, but I’ll ask what many people have already asked in forums at great length – how about an independent security audit?

  • Joe Siegrist says:

    @Anonymous (and anyone) If you comment immediately disappears it’s because blogger (our host) has marked it as spam — you can email and we’ll restore it like we’ve restored yours.

    To answer the assertion the XSS and the decryption key have to be in the same place at the same time. So if you take Mike’s example — if you did an XSS, and then on that XSS page you entered your username and password you would then have all the elements you would need to take this further.

    Is that practical? No. Getting someone to type their LastPass master password into an iframe’d version of when they weren’t going to LastPass to begin with, the domain name at the top is wrong and they ended up there because they were visiting nefarious site would set off just about anyone’s alarm bells many times over.

    The username and password are required because your encryption key is not with your session — we at LastPass don’t have it. Your session just gets you access to the data Mike got.

    We’ve feared a ‘persistent’ XSS more than any other threat — a persistent XSS means it sticks around in our database and is a far more dangerous attack. It’s more dangerous because it could potentially be on a page that has your encryption key. It’d also be a lot harder to pull off: It’d require something like what Mike found, and on top of that something even harder — a persistent XSS request that we would play back to the user at the right time.

    So while I’d say that nearly any XSS would be of limited impact, there is that outside chance and that’s why we’ve dropped everything to focus on CSP for Firefox 4, and adding something like it to all our browser extensions. This renders even the very low potential threat of a persistent XSS useless: any data that was gathered can’t leave the page.

  • Anonymous says:

    WOW, my comment regarding mike disappeared