Clickjacking is still very possible in 2024, because iframe embedding is allowed by default. Why is this the case?

In 2013 there was a question about why iframes exist at all (Why are iframes allowed at all in modern browsers?), which is outdated (it heavily reference Flash, Java Applets, and extols the benefits of using iframes for single domain sites as an alternative to AJAX).

However, EVEN assuming all the justifications for iframes from 2013 still hold up today, this does not explain why iframes aren't disallow by default (with CSP or X-Frame-Options being used to allow them when necessary).

  • 8
    "a question about why iframes exist at all which has now become extremely deprecated" - has it? What makes you think it is deprecated? Most of the answers still hold.
    – Bergi
    Jan 21 at 13:08
  • 8
    A better question would be why click-transparent iframes are allowed at all.
    – Joshua
    Jan 21 at 23:39
  • @Joshua, I think more than just transparency needs to be addressed. One could place the iframe behind some UI that the user is likely to click, and then use "pointer-events: none" on said UI. Maybe this could be prevented by forcing iframes to always be on top and visible. Although even then, one could just move the iframe 50ms after hover, which would probably catch a lot of people who click before realizing the button has become obscured.
    – yeerk
    Jan 24 at 18:49
  • @Bergi from the top post "GMail is made from iframes. ... Again, this could be implemented in AJAX, but it's harder", as well as "the arguments in this question could be equally applied to Java applets. Or Flash". Given the removal of flash, this is now an argument against iframes, not for it. The 2nd top post mentions payment systems need iframes, where are most systems are moving to redirects (due to safety). Another post: "99% of videos are presented in iframes - including Youtube, vimeo, Vk". Did you honestly read the other posts and think "flash, that's still relevant"?
    – yeerk
    Jan 24 at 18:51
  • 1
    @yeerk On the contrary. Since applets and flash have been deprecated, iframes are the only choice left for embedding foreign resources with reasonable sandboxing. They are the web-native solution to the problem. Lots of pages rely on them, which is why no browser can remove support for them. And that hasn't really changed since 2013.
    – Bergi
    Jan 24 at 19:38

3 Answers 3


Iframes are an important separation mechanism, which allow embedding of external content (like ads) into an HTML page in a restrictive way while still being able to interact with this content using Javascript if necessary. Without iframes the external content would need to be embedded directly into the original page, with no enforced restrictions - it would basically be XSS.

you could just allow iframes when you need them

The problem is not that malicious pages could create their own iframes. Iframes are created by the original HTML to embed external sites, not by the external site to embed themselves into other sites to attack these. I.e. the very site which creates the iframes also controls the CSP.

It would be another thing to have iframes more restrictive by default. Unfortunately suddenly changing the behavior of widely used components inside an existing environment will break things. Because of that there are many similar insecurities in other parts of web development, like allowing inline script by default, having a wide open content security policy if none is given (or a typo disabled one accidentally), not restricting the origin in the postMessage API by default, ... As a developer one needs to be aware of all these inherent design problems and explicitly harden the application, instead of being able to rely on more secure behavior by default.

  • @Kaiido: "you can check the event's origin" - this "can" means that there is no secure default. The receiver must explicitly check if the origin is the expected one and this check can easily be forgotten. Jan 23 at 3:35
  • 1
    @Kaiido: I've changed the phrase to make clear that it is about the default behavior Jan 23 at 8:52
  • Thanks (though postMessage() does restrict to same-origin by default, it's only the receiving end that does not, but that becomes less than nitpicking so it's probably fine as is).
    – Kaiido
    Jan 23 at 9:01
  • 1
    @yeerk: The problems with Flash or Java were much more serious than with click-jacking using iframes. There were basically zero days every other week which could compromise the whole system in drive by download attacks with no mitigation in place. And even then it took a long time to remove these plugins, because first functionality which could replace these plugins had to be integrated in a secure way into the browsers together with a relevant ecosystem using these features. Click-jacking using iframe is rare and the impact is much lower, so there is not that much pressure. Jan 24 at 19:11
  • 1
    @SteffenUllrich, fair enough, "cost vs risk" is a good point. I think that's probably the best explanation, and the reason it hasn't changed is the inherent subjectivity on how high/low the cost is, and how much risk there is.
    – yeerk
    Jan 24 at 19:17

As in many cases, it largely comes down to backwards compatibility. If Iframes were a brand new thing being created today, then they'd probably be opt-in rather than opt-out.

But changing that now would be a significant breaking change for many applications, and clickjacking isn't considered a serious enough problem to implement such a disruptive change, when there's an easy way for website to opt out of Iframes if they don't want to allow them.


The reason is, as others have pointed out, purely historical. Iframes were intended as a way to make "mashup" pages that included content from a bunch of sources, and the idea that you had to ask those sources for permission probably never crossed anybody's mind because, like, who cares? If they want to rip your content off quietly they can just copy the HTML themselves? And then came webapps and with them clickjacking, and upended the entire argument for why unrestricted embedding is fine. HTTP standards orgs moved too slowly, so Microsoft came out with the X-Frame-Options non-standard header, which was quickly at least mostly adopted by other browser vendors too. But even once it reached widespread use, and when the standardized CSP frame-ancestors directive came out, the default was still to always allow unless specifically prevented, because that was the way the web had always worked and it would be a big breaking change to fix it.

On the other hand, consider that the modern webapp security model is a gigantic pile of hacky fixes - some themselves compatibility-breaking[1] - stapled onto something whose designers didn't envision it being used for anything like its current usage. Various browsers have been implementing various fixes - without, and sometimes in violation of, standards[2] - for these issues for as long as webapps have existed, and the better ones became widespread or even standards themselves (though it's dangerous to depend on non-standardized behavior[3] for security). Meanwhile the standards have also changed, deprecating or outright prohibiting behavior that was itself once standard or at least widespread.

Given all that, I think it'd be entirely reasonable to announce - with some substantial phase-in period - a change to how iframes (and other embedded contexts) work. For example, making it so that if the external site doesn't explicitly consent to being framed, the page is loaded anonymously (no cookies or local/session storage; in effect, a subset of what Safari started years ago but for security rather than privacy reasons). This would break some sites, so you'd want to announce it beforehand, but it's worth noting that samesite on cookies already partially achieves this goal, and we made it through that transition. Taking it a bit further (isolating script storage and even samesite=None cookies when the page is embedded unless something else is set to explicitly allow embedding) seems reasonable.

[1] Perhaps most notably the change in cookie behavior when samesite=Lax became the default, though there are others.

[2] See for example the extreme measures Safari has taken to prevent tracking, which is a laudable goal but breaks legitimate websites that expect things like third-party cookies or even data storage in cross-origin iframes to act as per standards.

[3] E.g. servers that check for the Origin header to detect CSRF just because Chrome started adding it on all cross-origin requests including non-CORS ones, even though that isn't the original;y standardized use of Origin and was for a long time behavior only found in Chrome-like browsers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .