Currently, we have a small personal project which is meant to allow people to create 'profiles' in HTML/CSS. We aim to put all this generated content within a sandboxed iframe. The next point in discussion comes from allowing scripts in these iframes since users will be able to enter whatever content they want.

Couple things to note:

  • The site has a cross-origin policy of: allow-all
  • Authorization is handled through tokens stored within a React app. Not cookies.

I am mostly curious on the security risks of such a design and I have not found a clear concise answer. Should allow scripts within these iframes? or does this pose too much of a risk? What type of attacks are we looking at through an iframe? I am concerned mostly with XSS-type attacks. What about browser vulnerabilities with iframes?

  • So to be clear, the profiles will be published by the people in question and hosted on their own sites, and then you are going to include those sites in yours via iframes? – Conor Mancone Sep 11 at 17:47

iframes are executable so I don't think they are sandboxed; it's just another document (hosted separately) inside the primary document.

Which then obviously brings general xss or even possibly xsrf issues. The 'trust' is with the domain you're allowing (in this case your own) so it shouldn't be an issue per say.

here's an in depth answer

The IFRAME element may be a security risk if your site is embedded inside an IFRAME on hostile site. Google "clickjacking" for more details. Note that it does not matter if you use or not. The only real protection from this attack is to add HTTP header X-Frame-Options: DENY and hope that the browser knows its job.

In addition, IFRAME element may be a security risk if any page on your site contains an XSS vulnerability which can be exploited. In that case the attacker can expand the XSS attack to any page within the same domain that can be persuaded to load within an on the page with XSS vulnerability. This is because content from the same origin (same domain) is allowed to access the parent content DOM (practically execute JavaScript in the "host" document). The only real protection methods from this attack is to add HTTP header X-Frame-Options: DENY and/or always correctly encode all user submitted data (that is, never have an XSS vulnerability on your site - easier said than done).

That's the technical side of the issue. In addition, there's the issue of user interface. If you teach your users to trust that URL bar is supposed to not change when they click links (e.g. your site uses a big iframe with all the actual content), then the users will not notice anything in the future either in case of actual security vulnerability. For example, you could have an XSS vulnerability within your site that allows the attacker to load content from hostile source within your iframe. Nobody could tell the difference because the URL bar still looks identical to previous behavior (never changes) and the content "looks" valid even though it's from hostile domain requesting user credentials.

If somebody claims that using an element on your site is dangerous and causes a security risk, he does not understand what element does, or he is speaking about possibility of related vulnerabilities in browsers. Security of tag is equal to as long there are no vulnerabilities in the browser. And if there's a suitable vulnerability, it might be possible to trigger it even without using , or element, so it's not worth considering for this issue.

However, be warned that content from can initiate top level navigation by default. That is, content within the is allowed to automatically open a link over current page location (the new location will be visible in the address bar). The only way to avoid that is to add sandbox attribute without value allow-top-navigation. For example, . Unfortunately, sandbox also disables all plugins, always. For example, Youtube content cannot be sandboxed because Flash player is still required to view all Youtube content. No browser supports using plugins and disallowing top level navigation at the same time.

Note that X-Frame-Options: DENY also protects from rendering performance side-channel attack that can read content cross-origin (also known as "Pixel perfect Timing Attacks").

found here

  • The answer you linked to talks about the security of iframes in general, and as a result most of it is not relevant to the question actually being asked. – Conor Mancone Sep 11 at 17:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.