IFRAMES ARE UNSAFE! 😱
SO ARE HYPERLINKS! (? 🤔 )
SO ARE IMAGE TAGS! (ok what is this guy talking about 😠 )

The first one sounded believable didn't it? The other two sounded insane! Well if you consider iframes unsafe, you should consider the other two unsafe as well. Read along to find out as to why.

Having so many iframes involved in crime has given iframes a bad name. 😠

But let's break it down a bit. Let's explore the final boss of web crimes, the underdog of all things phishy, the underrated cross site scripting crimes-> The criminal practices that are possible via iframes. The Criminal Syndicate of Iframes. (*Godfather theme music starts playing*).

The iframe element in itself is the oldest and simplest content embedding technique in web development. The element itself is very stable. The challenges that surround it are mostly in the form of implementation and how somebody else opens your website in an iframe. Ensuring its clear, IFRAMES ARE NOT IMPLICITLY UNSAFE. THE CONTENT INSIDE IT MAY BE MALICIOUS.
But they are used for crime, regardless of how good they are in their hearts.
When you integrate an iframe, it is important to have a low trust approach towards it, because there are a number of security threats that can occur if you let it. This is especially true if you are working on something critical like payments. Also a lot of threats can occur when your website is opened up in an iframe. The issues that can happen are as follows:

Clickjacking

This is one of the most common and easy to implement threats on your website. In this scenario a button or a HTML element is added on top of the main content which redirects the user elsewhere, this could be an invisible element as well on top of visible content. Not just redirect, they could also download malware, share sensitive data and make online purchases. Historically Twitter as well as Facebook have suffered from such attacks.

How it works is, your website is opened as an iframe in somebody else’s website (an attacker) who plans on running some code behind the scene to manipulate a user to carry out some task. This can be prevented by the server side header of X-Frame-Options which will dictate to allow your website to open up inside an iframe or not. A newer update of CSP P(Content Security Policy) supports a directive called frame-ancestors which carries out the same in modern browsers.

iframe Injection

At times you could have an iframe on your website, which you don't know the source of. Usually how it could function is you open an iframe in your website and that decides to mount a div or an invisible div on top of an existing button in your website so as to redirect you elsewhere.To tackle this you will have to use client-side limitations to the iframe.
The attribute called ‘sandbox’ without a value of ‘allow-top-navigation’ helps prevent the same.

<iframe sandbox="allow-forms allow-scripts" ...>

But the problem with this is that the ‘sandbox’ attribute disabled all plugins. Historically YouTube couldn't be opened with a sandbox attribute because Flash player was still required to view its content. But in 2023 you might not require any plugin to display something in an iframe so you can use this attribute if you wish to.

Although this example did revolve around redirection, there could be other operations happening behind the scenes in a rogue iframe without you being aware of what it actually does. So it's best to find out and investigate the source for it to eliminate it.

Cross Frame Scripting (XFS)

XFS attackers persuade a user to visit a web page regulated by the attacker and loads an iframe combined with malicious JavaScript referring to a legitimate site. This might sound pretty similar to Clickjacking but there is a key difference. The difference being, in Clickjacking the interaction of user is between them and the attacker’s iframe/HTML element whereas here the interaction of user is between them and your HTML element. The malicious JS code here can track keystrokes and try to collect information surrounding lets say your credentials. Similar to Clickjacking the solution here is to set Content-Security-Policy to frame-ancestors and X-Frame_options to either deny or same-origin depending on your use case.

iframe Phishing

In Iframe Injection the example I discussed where this is a redirection, is how an Iframe Injection turns into Iframe Phishing. Iframe Injection could be dormant. It could be collecting information to use later on. In Iframe Phishing, it is more aggressive, essentially attempting to fool a user into believing. How so? Let's say you are on Facebook (around 2010s when such attacks were common). You see something on a fan page and click on it, and suddenly you get redirected to a Facebook sign in page. You are confused but you still decide to login into it. Only if you had seen the URL you would have noticed it's not Facebook’s. Oh no! You have been Phished!.

An attacker might leverage cross-site scripting (XSS) vulnerability on a web application to insert phishing code as an iframe to lead the user into a phishing website.

<html>  

<head>    

<title>Vulnerable Website.</title>  

</head>  

<body>  

<iframe src=”/user/genuine/” width=”1000″ height=”250″ frameborder=”0″>

</iframe>  

<iframe src=”http://fakebook.com/phished-login” width=”1000″ height=”250″ frameborder=”0″>

</iframe>  

</body>

</html>

If you are not attentive enough as a user you might fall in this trap. So the same solution as given before of not allowing redirects triggered by an iframe is a must. (remember? Sandboxing the iframe?) The sandboxed iframes can still open up websites on other tabs so you better trust the domain you are putting in an iframe if you want to prevent an iframe opening up an exact copy of your website in another tab and try to steal user credentials.

If an iframe is hosted inside a website which is vulnerable to XSS (Cross Site Scripting), then it is a security risk. But in that case it does not matter if it's an <iframe ..> or a <a..> or an <img.. > tag, because all of these have EQUAL level of security. Now does it mean you stop using these?

Well you can try doing that OR you can remove XSS vulnerabilities from the website.

Summing it up, the family of iframes is riddled with crime and security risks. But iframes are just victims to circumstances. Implicitly they are as secure as any other tag. Involvement of only a handful of iframes in crime such as above has led to a bad name for iframes, marking them unsafe. They are as good as any other tag, let it be a script tag, a hyperlink tag and an img tag. Justice for iframes!

iframes make you an offer you cannot refuse, which is to embed your content in somebody else’s website or embed somebody else’s content inside your website. You just need to be careful when opening it up or having your website opened up in an iframe. Other than that, you have nothing to worry about!