Cannot display my rails 4 app in iframe even if 'X-Frame-Options' is 'ALLOWALL'
Asked Answered
C

8

46

I am trying to test a responsive design. I am using Rails 4. I know it sets 'X-Frame-Options' to SAME ORIGIN. So I overrided it in development.rb using

config.action_dispatch.default_headers = {
    'X-Frame-Options' => 'ALLOWALL'
  }

and it worked. I checked out the network request in the Chrome console and it is as follows:

enter image description here

But still websites like responsive.is and responsinator.com give me below error:

Refused to display 'http://localhost:3000/' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'. about:blank:1

Whats going on??

Compline answered 9/7, 2013 at 7:32 Comment(1)
ALLOWALL isn't a valid value for X-Frame-Options (tools.ietf.org/html/rfc7034), although most browsers ignore the header completely when the value is invalid.Unmindful
E
28

I had the same problem as you, and searched for a solution to this problem all night.

I finally found out why it happens. It's because of the Chrome cache.

You can see the header['X-Frame-Options'] is ALLOWALL but it doesn't work.

Just try to open a "New Incognito Window" and go the same page and it works!

This problem only happened in development mode in my test. It worked fine in production mode.

Eupheemia answered 15/8, 2013 at 2:13 Comment(3)
@Timrael's answer fixed it for me, but Chrome caching was definitely a problem too - +1 for Incognito!Microscopic
For future reference: ALLOWALL is not a permitted value according to RFC it would be surprising if it worked.Letreece
Just FYI: Chrome Dev Tools has the option to allow caching, although it's not on by default. So results may be inconsistent.Dimple
G
72

Try just to delete this header 'X-Frame-Options'. Maybe this way in controller:

before_filter :allow_iframe_requests
...
def allow_iframe_requests
  response.headers.delete('X-Frame-Options')
end
Grane answered 25/7, 2013 at 15:28 Comment(4)
You can use this for apply this change for the whole application > #16561566Bova
Thanks. This is great because I get to choose only which method dismisses this option. There must be a reason why Rails devs enabled this by default; so I'd better keep (potential?) "vulnerability holes" as little as possible.Namely
This is the correct answer, because ALLOWALL isn't a valid value for X-Frame-Options (tools.ietf.org/html/rfc7034). The absence of the header will make the browser "allow all" originsUnmindful
Great solution! I really like that it allows iframe requests for select views instead of whitelisting the entire app.Frans
E
28

I had the same problem as you, and searched for a solution to this problem all night.

I finally found out why it happens. It's because of the Chrome cache.

You can see the header['X-Frame-Options'] is ALLOWALL but it doesn't work.

Just try to open a "New Incognito Window" and go the same page and it works!

This problem only happened in development mode in my test. It worked fine in production mode.

Eupheemia answered 15/8, 2013 at 2:13 Comment(3)
@Timrael's answer fixed it for me, but Chrome caching was definitely a problem too - +1 for Incognito!Microscopic
For future reference: ALLOWALL is not a permitted value according to RFC it would be surprising if it worked.Letreece
Just FYI: Chrome Dev Tools has the option to allow caching, although it's not on by default. So results may be inconsistent.Dimple
L
26

Rails 4 added a default X-Frame-Options HTTP header value of SAMEORIGIN. This is good for security, but when you do want your action to be called in an iframe, you can do this:


To Allow all Origins:

class MyController < ApplicationController
  def iframe_action
    response.headers.delete "X-Frame-Options"
    render_something
  end
end

To Allow a Specific Origin:

class MyController < ApplicationController
  def iframe_action
    response.headers["X-FRAME-OPTIONS"] = "ALLOW-FROM http://some-origin.com"
    render_something
  end
end

Use :after_filter

When you need to use more than one of your action in an iframe, it's a good idea to make a method and call it with :after_filter:

class ApplicationController < ActionController::Base

  private
  def allow_iframe
    response.headers.delete "X-Frame-Options"
  end
end

Use it in your controllers like this:

class MyController < ApplicationController
  after_filter :allow_iframe, only: [:basic_embed, :awesome_embed]

  def basic_embed
      render_something
  end

  def awesome_embed
      render_something
  end

  # Other Actions...
end

Do a Hard-Refresh in your browser, or use another browser to view changes

Via: Rails 4: let specific actions be embedded as iframes

Lamarckism answered 11/3, 2015 at 5:56 Comment(1)
Support for ALLOW-FROM is not broad: doesn't work in Chrome or Safari. See #10658935 and developer.mozilla.org/en-US/docs/Web/HTTP/…Arellano
I
9

When 'Load denied by X-Frame-Options' using Heroku & Firefox

I had a similar issue where I kept getting this error only on Firefox. I had a PHP web page hosted @ MochaHost serving a Rails app hosted @ Heroku (so RoR app has a page with an iframe which is pointing to the PHP web page and this working on all browsers except on Firefox).

I was able to solve the problem by setting a default header for all of my requests in the specific environment file:

# config/enviroments/production.rb

config.action_dispatch.default_headers = { 'X-Frame-Options' => 'ALLOWALL' }

Edit (as sheharyar suggested)

Ideally, you shouldn't set a default header and do this only for actions that have to be rendered in an iFrame. If your entire app is being served inside an iFrame, you should explicitly mention the Origin:

# config/enviroments/production.rb

config.action_dispatch.default_headers = { 'X-Frame-Options' => 'ALLOW-FROM http://some-origin.com' }
Inkberry answered 23/4, 2015 at 0:25 Comment(3)
It's not a good idea to pass 'X-Frame-Options': 'ALLOWALL' header for all requests. Ideally you should do this only for the actions being rendered in the iframe. If your entire app is being served inside an iframe, then you should specify the Origin in the Header: {'X-Frame-Options' => 'ALLOW-FROM http://some-origin.com'}Lamarckism
i agree with you and really like this approach i'll test this out and let you know but the concept is more than likely, it's perfect! ( i have done this for other languages and you are more than right )Inkberry
ALLOW-FROM is not supported by Chrome and Safar as per developer.mozilla.org/en-US/docs/Web/HTTP/…Idocrase
F
1

Try ALLOW-FROM http://example.com instead? ALLOWALL might be ok in Chrome if you have a sufficiently new version of Chrome [2]

[1] https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options

[2] https://mcmap.net/q/373012/-invalid-39-x-frame-options-39-header-from-google-39-s-doubleclick-response

Foredeck answered 20/7, 2013 at 13:12 Comment(0)
H
0

I found another cause for this. Assuming the ALLOWALL or similar fix is implemented, the next gotcha is attempting to use http content in a https website which causes security risks and is blocked by mozilla, IE and probably other browsers. It took me 6 hours to identify this, hopefully by sharing I can reduce someones pain...

It can be checked by:

  • using your browser web-tools which should display an error.
  • web logs will lack any connection with your supplying site.
  • replace your contents url with a banks https home page should demonstrate the iframe otherwise works.

The solution is to ask the source if they have https content or find another supplier.

ref:

Heartwarming answered 21/9, 2015 at 21:9 Comment(0)
L
0

I just wanted to give an updated answer here on dealing with embedding a Rails app in an iframe.

Its not a great idea to simply delete X-Frame-Options headers without having some other kind of security enforced to prevent against Clickjacking (which is the vulnerability X-Frame-Options is largely trying to protect you from).

The problem is that the X-Frame-Options 'ALLOW-FROM' option is not accepted on most major browsers anymore.

As of writing this, May 28th 2020, the best solution for preventing Clickjacking and hosting your app in an iframe is to implement a Content-Security-Policy and set a 'frame_ancestors' policy. The 'frame_ancestors' key designates what domains can embed your app as an iframe. Its currently supported by major browsers and overrides your X-Frame-Options.

You can set up a Content-Security-Policy with Rails 5.2 in an initializer (example below), and for Rails < 5.2 you can use a gem like the Secure Headers gem: https://github.com/github/secure_headers

You can also override the policy specifications on a controller/action basis if you'd like.

Content-Security-Policies are great for advanced security protections. Check out all the things you can configure in the Rails docs: https://edgeguides.rubyonrails.org/security.html

A Rails 5.2 example for a Content-Security-Policy:

# config/initializers/content_security_policy.rb    
Rails.application.config.content_security_policy do |policy|
  policy.frame_ancestors :self, 'some_website_that_embeds_your_app.com'
end

An example of a controller specific change to a policy:

# Override policy inline
class PostsController < ApplicationController
  content_security_policy do |p|
    p.frame_ancestors :self, 'some_other_website_that_can_embed_posts.com'
  end
end
Lambrequin answered 28/5, 2020 at 23:9 Comment(0)
C
-2

If you want to have this change take effect in all environments, place it in application.rb.

Clericals answered 12/12, 2014 at 22:36 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.