make x-frame-options configurable

For my projects I definitely need the Allow from possibility configurable. Any plans on incorporating this?

I'll see what we can do here.

Patch attached which provides the ability for the user to override the X-Frame-Options header if they know what they are doing. Personally, I don't think we should provide a UI for setting this so we can keep it as an option only for those folks who intentionally dig for it.

I'm also tagging this as needing a security review since this was added as security hardening and I'm not sure if adjusting said security hardening is something they would be up for.

Hi there,

Tried to use header X-Frame-Options with ALLOW-FROM and received the following error when loading the parent page/domain in Chrome:

Invalid 'X-Frame-Options' header encountered when loading 'http://embed.childdomain.com/path': 'ALLOW-FROM http://www.parentdomain.com' is not a recognized directive. The header will be ignored.

The embedded content/page still loads tho. However, turns out that ALLOW-FROM is not supported in Chrome (it seems to be fine in Firefox and IE): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Option...

Alternatively, using header Content-Security-Policy seems to do the trick (without errors in Chrome). Here's what I added to my custom EventSubscriber (implements EventSubscriberInterface):

class MyModuleEventSubscriber implements EventSubscriberInterface {

  /**
   * Set header 'Content-Security-Policy' to response to allow embedding in iFrame.
   */
  public function setHeaderContentSecurityPolicy(FilterResponseEvent $event) {
    $response = $event->getResponse();
    $response->headers->remove('X-Frame-Options');
    $response->headers->set('Content-Security-Policy', "frame-ancestors 'self' parentdomain.com *.parentdomain.com", FALSE);
  }

  /**
   * {@inheritdoc}
   */
  static function getSubscribedEvents() {
    // Response: set header content security policy
    $events[KernelEvents::RESPONSE][] = ['setHeaderContentSecurityPolicy', -10];
    
    return $events;
  }

}

Note that X-Frame-Options needs to be removed to prevent Firefox from applying it.

In order to call that EventSubscriber you need to define it as service in your module's services.yml file (e.g. my_module.services.yml) and tag it as event_subscriber:

services:
  my_module_event_subscriber:
    class: Drupal\my_module\EventSubscriber\MyModuleEventSubscriber
    tags:
      - {name: event_subscriber}

As showsn in #6 this is something one can change via a subscriber. This IMHO seems to be the much better place than a configuration option in the UI>

Maybe I am not the right person to ask about this, because I have to create a subscriber for every site I build since I embed them in my own portfolio. But still, it would be nice if it was easier to change this header.

@Lukas von Blarer
Yeah I don't disagree with it. One thing we could do is to use a container parameter to configure that. This requires much less effort, and well I doubt we really need a configuration UI for this specific property :)

Sounds good.

Its great that we agree here :)

Please see and discuss #2820340: "X-Frame-Options" deprecated, use "frame-ancestors" in core instead? before putting too much energy into this.

Why is this set in the first place without the ability to set it? That's insane, and breaks drush run-server functionality if you need to test iframes. This entire thought seems like an overstep in core, especially if it's not configurable, or being replaced with the followup header.

@sitiveni thanks!

Your solution works perfectly.

We found another module that does the trick:

https://www.drupal.org/project/seckit

It has several options, but one is to disable the clickjacking setting. We tested it out on a few sites and works like a charm.

#6 worked for me! Thanks @sitiveni!

For security, I slightly modified the function to lock it down to a specific, trusted domain:

  public function setHeaderContentSecurityPolicy(FilterResponseEvent $event) {
    $referer = $event->getRequest()->headers->get('referer');
    if (strpos( $referer, 'https://www.example.com/' ) === 0) {
      $response = $event->getResponse();
      $response->headers->remove('X-Frame-Options');
      $response->headers->set('Content-Security-Policy', "frame-ancestors 'self' example.com *.example.com", FALSE);
    }
  }

I have allowed a Drupal page to display in iframe for all other websites by updating HTTP header "X-Frame-Options" to 'GOFORIT' as given below for Drupal 7

drupal_add_http_header('X-Frame-Options', 'GOFORIT');

I have used this code in a project and its verified.

For Drupal 8, please use the same according to Drupal 8 syntax.

This is not solved for core in general. Please stop closing issues which you solved by a workaround only for yourself.
Also stop to change the version unintentionally!

Thanks, I understand it and will take care onward.

Path to the test being modified has changed in recent core updates, so I have updated the patch to match.

Finally got around to fixing the tests. Re-rolled for 8.8.x-dev.

Now with added Migrate test fixes...

I think patch works great and was able to embed the page on my second site. I am changing one thing which is missed in the patch i.e. the form element in the site configuration so there was no option to add the domain name, I added that in the new patch and have tested it with 9.0.7.

Thanks,
Sadashiv.

The X-Frame-Options ALLOW-FROM options is obsolete for new browsers, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Option...

I would recommend leaving this to contrib modules like seckit where you can use the new CSP frame-ancestors directive.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

We should postpone this on the results of #2513356: Add a default CSP and clickjacking defence and minimal API for CSP to core and afterward decide, how to proceed here.