[wp-trac] [WordPress Trac] #40020: Customizer fails to load in Safari due to X-Origin Header mismatch

[WordPress Trac]

#40020: Customizer fails to load in Safari due to X-Origin Header mismatch
-------------------------------+------------------------------
 Reporter:  nickkeenan         |       Owner:
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Customize          |     Version:  4.7.2
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+------------------------------

Comment (by jeremyfelt):

 I'm able to reproduce this in Safari 11.0.1 when Nginx has a `add_header X
 -Frame-Options SAMEORIGIN always;` directive applied. Safari sees
 conflicting rules and then falls back to `DENY`.

 When the directive is removed in Nginx, the Customizer frame loads, but
 Safari still reports an error that `ALLOW-FROM http://wp.wsu.dev/wp-
 admin/customize.php` is not a recognized directive for `X-Frame-Options`
 and ignores the header.  Safari and Chrome [https://caniuse.com/#feat=x
 -frame-options do not support] `ALLOW-FROM`

 In my case, I *believe* it's safe (in custom code) to remove the `ALLOW-
 FROM` header and rely on the `SAMEORIGIN` provided by Nginx and the
 `frame-ancestors` CSP provided by core Customizer code.

 I'm not sure that it makes sense as a change in core, so it may be okay to
 close this ticket as a config conflict that's best handled on a case by
 case basis.

 FWIW, `X-Frame-Options` is deprecated and `frame-ancestors` is a
 [https://caniuse.com/#feat=contentsecuritypolicy2 well supported]
 replacement. Once IE11 fades off some more, it may be possible to rely on
 `frame-ancestors` alone.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40020#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform