# Browser prevents Discourse from rendering in iframe despite proper configuration (\`X-Frame-Options: SAMEORIGIN\`)

**URL:** https://meta.discourse.org/t/browser-prevents-discourse-from-rendering-in-iframe-despite-proper-configuration-x-frame-options-sameorigin/335746
**Category:** Bug
**Tags:** embedding
**Created:** [November 12, 2024, 11:21am UTC](https://meta.discourse.org/t/browser-prevents-discourse-from-rendering-in-iframe-despite-proper-configuration-x-frame-options-sameorigin/335746 "2024-11-12T11:21:23Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![phoulgaux](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/phoulgaux/32/458858_2.png) [@phoulgaux](https://meta.discourse.org/u/phoulgaux)
#### Post date: [November 12, 2024, 11:21am UTC](https://meta.discourse.org/t/browser-prevents-discourse-from-rendering-in-iframe-despite-proper-configuration-x-frame-options-sameorigin/335746/1 "2024-11-12T11:21:23Z")

</div>

Hi all,

We have a Discourse instance embedded in an iframe within our application, and it’s working fine as such. However, when an unauthenticated user tries to access a page that they do not have access to (either doesn’t exist or is group-restricted), the response now mysteriously includes `X-Frame-Options: SAMEORIGIN` and browsers block the frame from rendering.

I checked on different versions starting with 3.3.1 stable to almost current bleeding edge (last tested mid-last-week).

It’s running on a different subdomain than the parent app and configured for embedding with `allow_embedding_site_in_an_iframe: true` and by debugging a clean instance, I noticed that in such a case, `conditionally_allow_site_embedding` method in `ApplicationController` is not called, thus leaving the header in response ([GH link](https://github.com/discourse/discourse/blob/6dfe2fbe16a4096ff342ec8b626ac62a19eaa180/app/controllers/application_controller.rb#L102)), and tracked it to throwing an exception at some point and thus breaking out of the flow.

Reproduction:

1. Run a clean instance of Discourse (or any instance actually – this happened in local, test and production environments) and configure it with `allow_embedding_site_in_an_iframe: true`.
2. Embed it into an iframe in a website served over HTTPS using a non-existent path to trigger a 404 error.

**Expected** : Browser allows Discourse to render.  
**Actual** : Browser prevents Discourse from rendering due to `X-Frame-Options: SAMEORIGIN` present in the response.

Sidenote: It’s running through a DNS-only Cloudflare and we tried to delete the header in proxy-mode, however, we cannot put it in proxy mode due to CF filtering out cookies which are required for our custom SSO implementation, so this is a no-option for us right now.