I'm testing clickjacking mitigation with a simple page like this on another domain:
<iframe src="https://my.domain/login"></iframe>
My login page sends the following headers:
HTTP/1.1 302 Found
X-Frame-Options: SAMEORIGIN
Location: https://my.domain/landing
...
I'm surprised to see both IE 10 and Chrome 33 follow the redirect and display my landing page inside the <iframe>
. My landing page does not send X-Frame-Options
, but I expected the first X-Frame-Options
on the login page to trump the redirect. How can I prevent browsers from following the redirect when my login page is displayed in a frame?
I should add that things work as expected (<iframe>
is empty/blocked) if the login page doesn't send an HTTP redirect.
From the terminology used in RFC 7034, I conclude that browsers will not apply X-Frame-Options restrictions for HTTP redirects (status codes 301, 302, etc), but rather for any response where the browser processes the content, e.g.:
The use of "X-Frame-Options" allows a web page from host B to declare that its content (for example, a button, links, text, etc.) must not be displayed in a frame (
<frame>
or<iframe>
) of another page (e.g., from host A). This is done by a policy declared in the HTTP header and enforced by browser implementations as documented here.
or:
The X-Frame-Options HTTP header field indicates a policy that specifies whether the browser should render the transmitted resource within a
<frame>
or an<iframe>
. Servers can declare this policy in the header of their HTTP responses to prevent clickjacking attacks, which ensures that their content is not embedded into other pages or frames.
As an alternative for the login page you could return a HTTP status code 200 and a meta-tag or javascript for redirection, the X-Frame-Option will then apply, but I admit that it's ugly.