About the Author

Chris Shiflett

Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.

Twitter Don't Click Exploit

I've been posting to Twitter more than my own blog lately, but I noticed a Twitter exploit today that I thought was worth sharing in more than 140 characters. You can try the exploit for yourself at the following URL:


Those who are exploited will post the following message to Twitter:

Don't Click: http://tinyurl.com/amgzs6

At first, I thought this might be a new CSRF exploit, but a closer look quickly ruled that out. If you view source on that page, you'll see an IFrame that loads Twitter with a message pre-filled:

<iframe src="http://twitter.com/home?status=Don't Click: http://tinyurl.com/amgzs6" scrolling="no"></iframe>

This is nothing new, because it's the same tactic Twitter itself uses to pre-fill the start of a reply when you click the reply button.

Below the IFrame is a button:

<button>Don't Click</button>

What makes this a neat trick is the use of clickjacking; when you click this button, you actually submit the form on Twitter.

But how?

Look closely at the CSS:

iframe {
    position: absolute;
    width: 550px;
    height: 228px;
    top: -170px;
    left: -400px;
    z-index: 2;
    opacity: 0;
    filter: alpha(opacity=0);
button {
    position: absolute;
    top: 10px;
    left: 10px;
    z-index: 1;
    width: 120px;

This positions the IFrame and button in such a way that Twitter's update button (in the IFrame) is positioned on top of the ordinary button on the page, but the IFrame is hidden from view, so you think you're clicking the ordinary button underneath it, but you're really clicking Twitter's update button.

I have a very simple example that demonstrates this without the opacity set to zero, so if you pay close attention while the page loads, you will see the Don't Click button until Twitter loads in the background, after which you'll see Twitter's update button rendering on top of it:


Pretty clever and a great example of clickjacking. Remember, this is clickjacking, not CSRF.

I wonder if this would be nearly as popular if the button were labeled Click instead of Don't Click. :-)

About this post

Twitter Don't Click Exploit was posted on Thu, 12 Feb 2009. If you liked it, follow me on Twitter or share:


1.Chris Shiflett said:

As I posted on Twitter:

Twitter is now using frame-busting techniques to help prevent #dontclick. It looks like the fun is over. For now. :-)

The example will still work, but as soon as Twitter loads in the IFrame, you'll be redirected to Twitter.

Thu, 12 Feb 2009 at 18:57:13 GMT Link

2.Wesley said:

To protect yourself, you can use the NoScript firefox extension:


Thu, 12 Feb 2009 at 19:05:28 GMT Link

3.Chris Shiflett said:

Yes, but Twitter's frame-busting uses JavaScript, so be sure you're using at least NoScript version or above, else you'll be more vulnerable than not using it at all.

Thu, 12 Feb 2009 at 19:12:39 GMT Link

4.Spacemonkey said:

TweetDeck and Safari FTW!

This attack is no good if you aren't logged in to Twitter via your browser.

I kept clicking, and clicking, and clicking. Nothing. Hrmph.

Thu, 12 Feb 2009 at 19:40:57 GMT Link

5.Darian said:


Please explain further your last comment about the need for NoScript version or above? I recognize, based on reading the Changelog that ClearClick was added in 1.8.2. But I'm unclear about what happened in

Thu, 12 Feb 2009 at 19:41:52 GMT Link

6.Chris Shiflett said:

Darian, that's just my mistake. I quickly searched to find what version included clickjacking protection and found a reference to

So, as a correction, make sure you're using NoScript 1.8.2 or above. :-)

Thu, 12 Feb 2009 at 19:51:13 GMT Link

7.Chris Shiflett said:

Thanks to Jeff Jones, the example now continues to work despite the frame-busting:


Thu, 12 Feb 2009 at 22:44:08 GMT Link

8.Chris Shiflett said:

For fun, I created a working demo with the opacity set to zero, just like the original:


Thu, 12 Feb 2009 at 23:11:42 GMT Link

9.Jeff Jones said:

I've blogged my thoughts on this attack, and ways I think it could be prevented: http://www.tetraboy.com/archives/5-Twitter-Clickjacking-Attack.html .

Fri, 13 Feb 2009 at 02:01:14 GMT Link

10.Chris Shiflett said:

It looks like Twitter now addresses the new example. Well done!

I haven't looked into what they're doing yet to know whether it offers strong protection that will last. Anyone want to have a look?

Fri, 13 Feb 2009 at 02:47:11 GMT Link

11.James said:

@Chris, they're now using a basic frame-breaking script to prevent clickjacking "attacks":

if (window.top !== window.self) {
    window.top.location.href = window.self.location.href;

Looks like the culprits just copied the source from my original PoC, posted 20th Jan.

Fri, 13 Feb 2009 at 20:22:58 GMT Link

12.James said:

Oops, ignore that last code snippet. The Twitter team have since updated the script to this:

if (window.top !== window.self) {

Fri, 13 Feb 2009 at 20:25:53 GMT Link

13.Jonathan Stark said:

I am sure everyone is going to goof on me, but I don't see the significance of the distinction being made between clickjacking and csrf in this exploit. I get that it's not executed in the same manner, but it could have been csrf just as easily, right? Who cares if I am clicking the actual button or an invisible overlay? Tougher for the target site to defend against, perhaps?

Tue, 17 Feb 2009 at 03:49:14 GMT Link

14.Chris Shiflett said:

Hi Jonathan,

I don't see the significance of the distinction being made between clickjacking and csrf in this exploit.

I think it's similar to the distinction made between something like session hijacking and phishing. As an astute user, I feel as if I can protect myself from phishing, whereas my session can be hijacked due to a vulnerability in the application, and I'm pretty helpless.

If Twitter had a CSRF vulnerability, this would also have spread much faster and affected far more people. Twitter used to have such a vulnerability:


So, I think properly identifying the root cause of the problem is important for two reasons:

1. It's an important distinction for Twitter when they try to fix it.

2. It's an important distinction for users who want to understand the extent of the risk.

Hope that explains a bit. Thanks for commenting.

Tue, 17 Feb 2009 at 05:03:36 GMT Link

15.Jonathan Stark said:

Thanks for clearing that up. #1 in particular makes sense to me. I was thinking of it more from the perspective of a site user rather than a site developer.

Thu, 19 Feb 2009 at 19:23:17 GMT Link

16.Sean Coates said:

To paraphrase:

Clickjacking requires the user to do something, explicitly (click on a button, or in this case, what LOOKS like a button).

CSRF requires only the user's BROWSER to do something, and this action is implicit on the user's part.

I visited the "don't click" site, but I actually didn't click the button, so I was not a victim. If this had been a CSRF vulnerability, my browser would have made me a victim without the [in]action on my part.


Thu, 19 Feb 2009 at 20:16:58 GMT Link

17.Chris Shiflett said:

The author of the exploit has posted a recap, and he graciously references my post. :-)

Read it here:


Sun, 22 Feb 2009 at 22:07:28 GMT Link

18.Tom Graham said:

Another twitter click-jacking vector: http://www.noginn.com/2009/02/25/twitter-click-jacking-fun/

Wed, 25 Feb 2009 at 21:33:09 GMT Link

19.Darryl said:

The same thing can be done with facebook shares.


Thu, 26 Feb 2009 at 03:26:17 GMT Link

Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.