I'm looking at code for an old login form I'm redesigning. It's a simple table with two input fields for username and password.

But just before the end </table> tag there's a blank iFrame which looks like

<iframe style="height:0px;width:0px;visibility:hidden" src="about:blank">This is a security measure.</iframe>

What possible security measures could this provide? I can't think of any and can't ask the guy who put it there in the first place.

  • The only thing that I can think of is that the iframe is holding a cookie of some description.
    – Sam
    Mar 25, 2013 at 23:06
  • 5
    Keep in mind that whoever put it there didn't necessarily know what they were doing. I've seen the most random things done in the name of "security", especially in legacy codebases.
    – Tacroy
    Mar 25, 2013 at 23:11
  • @Sam How could it hold a cookie of any description with a src of about:blank?
    – Caleb
    Mar 26, 2013 at 0:21
  • 5
    Michael is there any javascript in the form handler or validation routines that manipulates the content of the iframe? Is the iframe perhaps the target of the form and on receiving data it gives something back the posting page can process inline? Were they trying to trigger (or not trigger) a browsers password remember features?
    – Caleb
    Mar 26, 2013 at 0:23
  • @Caleb - It's hard to judge by the example alone, but my bet would be this file the HTML code is from serves as a template for some CGI script to later fill it with other required parts that are missing on HTTP request. Having JS parts in separate files is a good practice in a multiple developer environment, where each developer only receives files they'd need to be concerned with. It's also easier to track versions and apply code and/or design changes. Either way, chances are the example OP posted is the only part of it he has access to.
    – TildalWave
    Mar 27, 2013 at 11:51

1 Answer 1


It is a security measure, as the description in the code implies. The iframe serves as a protection mechanism against XSS exploits through browsers' own measures against these very same attack types by preventing JavaScript access to frames and iframes when they're not published on the same domain. It isn't really necessary to write this part of HTML directly in the document, as it could as well be written by the same JavaScript that is latter manipulating its contents, but the developer of this solution probably wanted to make it clear to future developers that some external script is verifying the log-in form before it's posted and that the browsers XSS prevention mechanisms are used to achieve better end-user security while signing-in. This is also strongly implied by the lack of an ID for the iframe, which would make referencing it so much easier.

Developer would then attach a JavaScript script element to iframe DOM with a code that would look something like this:

window.onload = function () {

    var iframe = document.createElement('iframe');
    iframe.width = "0px";
    iframe.height = "0px";
    iframe.style.visibility = "hidden";
    iframe.id = "noXSSframe";
    iframe.setAttribute("src", "about:blank");


    iframe.addEventListener('load', function (e) {
        var myElement = document.createElement('script');
        myElement.setAttribute('src', '/content/test.js');
        myElement.setAttribute('type', 'text/javascript');

    }, false);


This is just an example and is not necessarily the exact same method your developer chose, but should serve good enough for demonstration purposes.

This external JavaScript file that's just been attached to the iframe would then be written in such a way to account for being run through an iframe, referencing parent document object in a way that only a script located on the same domain is permitted, while any XSS injections replacing the called script with a script hosted outside of the parent document domain would clearly be denied access by browsers themselves. The only way to prevent browsers to enforce same origin policy for XMLHttpRequests is by attaching additional headers to the server's HTTP response and explicitly allowing cross-origin resource sharing (CORS). This however isn't something XSS injections alone can tamper with.

In short, it's an elegant way to make sure the JavaScript that's responsible for manipulating, verifying and ultimately posting a log-in form (preparing and initiating a HTTP request) is indeed loaded from a file hosted on the same domain the log-in form is on, effectively preventing simple XSS injections. At the same time, it also prevents phishing sites from reusing this log-in form and sending log-in requests to another domain, if the iframe script does some additional verification, attaching unique response values that can be verified server-end to the form's POST request.

  • 2
    Oh wow, thank you very much for the answer. Learned something new today.
    – user22679
    Mar 27, 2013 at 0:34
  • 1
    Is it typical for web applications to make the .js in extscript.setAttribute('src','somejavascriptfile.js'); dynamic and subject to XSS attacks? Perhaps I'm misunderstanding the threat. Mar 27, 2013 at 12:02
  • What would be a good example of a unique response value to be included in the POST for verification? Is a random nonce enough? Mar 27, 2013 at 12:03
  • 1
    @makerofthings7 - No, I wouldn't say it's typical but the part of the HTML code OP included suggests it was done so in this case. XSS attack can't simply replace that URI value and expect a script from a different domain he'd be attaching to have access to the parent DOM. The only way to exploit this process with XSS is, if an attacker can count on some already existing script hosted on the same domain that he could reuse, and the chances for that are rather remote. But it can be done by adding src value to the iframe directly as well, but might have not been to better support versioning.
    – TildalWave
    Mar 27, 2013 at 12:12
  • 1
    @makerofthings7 - A random nonce stored on the server on initial response, and then verified for same value and same request meta-data for both the external script and the end-user initiated POST request (i.e. session data). At least, that's how I'm doing it. I'm open to suggestions on how to improve this, if you see some potential problems with it, though. ;)
    – TildalWave
    Mar 27, 2013 at 12:15

You must log in to answer this question.