X-Frame-Options, SAMEORIGIN not loading SSL modal frame

I tried adding the following response headers for security reasons.

X-Frame-Options, SAMEORIGIN

It is working somehow meaning external website can no longer iframe my website.

However, I am encountering a problem.

On my website, I am loading a modal window in an iframe and that iframe is in https. If my base window is in http, that modal window cannot load even though they are from the same domain.

But if my base window is https, I have no problem loading that https modal window.

Any suggestion to make the https modal work even if my base is on http?

NOTE: The modal MUST be on https due to business requirements.

LVL 33
Who is Participating?
lenordisteConnect With a Mentor Commented:
come to think of it, I am not sure that a similar http and https uri can be considered as "same origin".

if your base uri is:  http://myshop.com/basket
and you are calling withing an iframe: https://myshop.com/login

I don't think this would be considered as being from the same origin and thus SAMEORIGIN option will fail. I tried to look up documentation reference on this and it is very unclear how each browser will react to this so it may just be the case that some may accept it has being the same origin and some won't.

If you cannot use Allow-From (very recent...) than you may be out of luck. My guess is that you added the header to prevent click-jacking, here are some alternatives that may be relevant: https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet

why can't you use your base page in https by the way?
Hi Hongjun,

loading an HTTPS iframe from within an HTTP page should be working fine, if not ideal. Are you sure there's not something else causing the problem?

that said, it is very bad practice to mix-match http/https contents using iframes and some browsers may fire security warning messages... if possible, you d be better off dropping the iframe all together and serve the content from a base https site.
hongjunAuthor Commented:
The iframe is a new modal window and not within a page. The modal is in https because it's a login page.

I am sure it is causing problem if it is initiated from a http page.

There is no problem if x-frame-options is not added.
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

have you tried setting X-Frame-Options ALLOW-FROM <your uri> instead?
hongjunAuthor Commented:
ALLOW-FROM not supported on Chrome and Firefox. So I cannot use.
hongjunAuthor Commented:
>>why can't you use your base page in https by the way?

Simple reason being the website is not only 1 or 2 pages. It is a huge website with many different modules/sections. The requirement is to secure only forms with sensitive information e.g. login, register, forget password, and so on. Securing the whole website may impact performance and certain CMS pages may run into problem if resources e.g. images having full path may end up the page with mixed secure+nonsecure content.

SAMEORIGIN seems to consider http and https to be different.
instead of using an Iframe, why don't you redirect your user to an https login/register/etc page when the need arises and keep the rest as plain http? This is by far the most common way to handle it. Without making too many breaking changes in your code, you could even implement it using rewrite rules.

One last option would be to open a pop up (I know...), but for login purposes users may find that acceptable.

What do you think?
hongjunAuthor Commented:
In reality, users will be unhappy if we were to change how they are doing things now since the website is in fact live.

Looks like there is no other options.

I shall wait and see if there are other inputs from other experts.
just redirect your users to SSL pages when needed, this won't break their current experience and will be as secured as can be. This is what's being done on most major sites.

Hopefully, someone may have a better idea that works for you.
hongjunAuthor Commented:

Redirecting all to https://...login.aspx when the login button is clicked is a break in experience since it is meant to be a modal window. Meaning, it won't have the header, masthead, footer, menu, etc. It will look totally different.

I end up using the following in <head>..</head> for all pages.

    <style id="antiClickjack">body{display:none !important;}</style>
    <script type="text/javascript">
    	if (self === top) {
			var antiClickjack = document.getElementById("antiClickjack");
		else {
			try {
				if (document.domain.toLowerCase().replace('www.','.')+'/' == document.referrer.split('/')[2].toLowerCase().replace('www.','.')+'/') {
					var antiClickjack = document.getElementById("antiClickjack");
					top.location = self.location;
			catch (errC) { top.location = self.location; }

Open in new window

I shall wait for other input.

Thanks for your time so far.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.