Frame Buster Buster … buster code needed

Frame Buster Buster … buster code needed

Let’s say you don’t want other sites to “frame” your site in an

So you insert anti-framing, frame busting JavaScript into all your pages:
/* break us out of any containing iframes */
if (top != self) { top.location.replace(self.location.href); }

Excellent! Now you “bust” or break out of any containing iframe automatically. Except for one small problem.
As it turns out, your frame-busting code can be busted, as shown here:

This code does the following:

increments a counter every time the browser attempts to navigate away from the current page, via the window.onbeforeunload event handler
sets up a timer that fires every millisecond via setInterval(), and if it sees the counter incremented, changes the current location to a server of the attacker’s control
that server serves up a page with HTTP status code 204, which does not cause the browser to navigate anywhere

My question is — and this is more of a JavaScript puzzle than an actual problem — how can you defeat the frame-busting buster?
I had a few thoughts, but nothing worked in my testing:

attempting to clear the onbeforeunload event via onbeforeunload = null had no effect
adding an alert() stopped the process let the user know it was happening, but did not interfere with the code in any way; clicking OK lets the busting continue as normal
I can’t think of any way to clear the setInterval() timer

I’m not much of a JavaScript programmer, so here’s my challenge to you: hey buster, can you bust the frame-busting buster?


Solution 1:

I’m not sure if this is viable or not – but if you can’t break the frame, why not just display a warning. For example, If your page isn’t the “top page” create a setInterval method that tries to break the frame. If after 3 or 4 tries your page still isn’t the top page – create a div element that covers the whole page (modal box) with a message and a link like…

You are viewing this page in a unauthorized frame window – (Blah blah… potential security issue)

click this link to fix this problem

Not the best, but I don’t see any way they could script their way out of that.

Solution 2:

FWIW, most current browsers support the X-Frame-Options: deny directive, which works even when script is disabled.


Firefox (3.6.9)


Solution 3:

We have used the following approach in one of our websites from

 body { 
 display : none   
if(self == top) {
document.getElementsByTagName("body")[0].style.display = 'block';
top.location = self.location;

Solution 4:

Came up with this, and it seems to work at least in Firefox and the Opera browser.

if(top != self) {
 top.onbeforeunload = function() {};

Solution 5:

Considering current HTML5 standard that introduced sandbox for iframe, all frame busting codes that provided in this page can be disabled when attacker uses sandbox because it restricts the iframe from following:

allow-forms: Allow form submissions.
allow-popups: Allow opening popup windows.
allow-pointer-lock: Allow access to pointer movement and pointer lock.
allow-same-origin: Allow access to DOM objects when the iframe loaded form same origin
allow-scripts: Allow executing scripts inside iframe
allow-top-navigation: Allow navigation to top level window

Please see:

Now, consider attacker used the following code to host your site in iframe:

<iframe src="URI" sandbox></iframe>

Then, all JavaScript frame busting code will fail.

After checking all frame busing code, only this defense works in all cases:

<style id="antiClickjack">body{display:none !important;}</style>
<script type="text/javascript">
   if (self === top) {
       var antiClickjack = document.getElementById("antiClickjack");
   } else {
       top.location = self.location;

that originally proposed by Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson (2010)

Solution 6:

After pondering this for a little while, I believe this will show them who’s boss…

if(top != self) {, '_top');

Using _top as the target parameter for will launch it in the same window.