We are looking to move to iframes due to technical challenges. By moving to iframes it will be easier to manage the technical issues. But we are not totally sure of security implications of iframes.

Our website is rendered through SSL and the user may need to click on the links also on SSL from our site.

  1. Is it possible to open it in a completely new browser and still have no security issues?
  2. What are the things we should keep in mind to make sure our site remains secure while using iframes?
  • 3
    What are the technical reasons? Why would you leave that out?
    – rook
    Apr 1, 2012 at 6:24
  • 3
    Please give some more details on your first question. It is rather unclear what you mean. Apr 1, 2012 at 9:21
  • Welcome secuirty.se, make sure to post enough information for people to actually answer your question.
    – rook
    Apr 1, 2012 at 16:33
  • @Rook and Hendrick - Currently we are using BHO/Extensions to connect to sharepoint and other SaaS application outside of our firewall. Its a homegrown system but to maintain the BHO/Ext is getting too much of a task. We were thinking iFrame would be a good alternative but are a bit vary of the security.
    – Mick
    Apr 2, 2012 at 3:51

4 Answers 4


Assuming the iframes have the same origin so that you do not have to remove the X-Frame-Options: sameorigin header, or that Clickjacking is not an issue in them. (There is a allow-from token specified, but older browsers don't support it).

The main remaining issue with using frame is, that you might end up displaying untrusted content, while the user still sees your domain in the address bar. For example there may be a link that is missing the target="_top" attribute or you might want to display foreign content intentionally.

This foreign content may for example display a form "Your session has expired, please login again" with your layout. The address bar will show your domain.

  • Hmm, yeah see mentioning the origin inheritance rules is pretty pretty important, because iframe's can be used as a security measure. Also old browsers are probably hacked to tears anyway.
    – rook
    Apr 1, 2012 at 16:32

A common security concern with iframes is clickjacking. This issue is commonly mitigated using the x-frame-options http response header. It is important to limit what pages can be iframe'ed. Pages that allow the user to change their password, modify settings should be limited have an x-frame-option of "deny".

There are major security befits from using an iframe. For example Google+ buttons rely upon the origin inheritance rules for iframe's for security.


iFrames can introduce many security issues depending on how they are implemented and where the content is being served.

Here are some details on iFrame options mentioned by Rook


If this is enabled, iFrames could phish for information, pose as a login form for your website etc.

allow-scripts If allow scripts is enabled, then there is no point in setting allow-forms, since a form can be created in the DOM by Javascript

If you allow scripts in an iFrame it could potentially perform DoS attacks, open browser dialogs, or perform automation on the page that could expose information to others (referer attribute) or load external objects.


This right allows the iFrame to act as the embedded site or or phish the users credentials.


This attribute is intended to display raw HTML documents (HTML email for example) unaltered from the source. The issue is that if the URL is predictable and the attacker can get the user to view the iFrame directly then the properties of the sandbox are lost. Worse still the opened web page might traverse the opener object and discover properties about the source page.

Finally, there is a propose MIME type called text/html-sandboxed for content that should always be viewed in a sandboxed environment, but many browsers misinterpret this and will display the data in unusual ways (usually a bad thing).


You should implement two things to secure that application:

1) Add X-frame-Option Headers ie in apache:

echo "Header always append X-Frame-Options SAMEORIGIN" >> /etc/apache2/httpd.conf && a2enmod headers && service apache2 restart

2) Add Framebusting Javascript code for old browsers.
Caution! if (_top == _self) is BAD Framebusting code!

Look here, there are many framebusting examples (OWASP Video).


You must log in to answer this question.

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