Customizer preview blocked by content security policy

[rahilwazir]

With the introduction of changesets (#30937) and previewing natural URLs as opposed to using document.write() to load the preview, Firefox specifically sometimes blocks rendering the preview due to a content security policy violation.

Originally reported at ​https://wordpress.org/support/topic/blocked-by-content-security-policy/

[westonruter]

As a fallback if we can’t figure out why Firefox is rejecting the iframe request, then the CSP header could be overridden to be removed entirely. I originally included it to override any other plugins that may have added the header to prevent their site from being iframed. But instead of specifying frame-ancestors as its value, the entire header could be removed instead if we also then include a preview nonce among the customized state query params. Nevertheless, if we can figure out why Firefox is rejecting it that would be best.

[westonruter]

@rahilwazir any update on your investigations?

[westonruter]

@rahilwazir please re-open if this issue persists or if you have any new findings.

[khromov]

I think this needs to be reopened, just came across the issue using VVV / OSX 10.12.2 / Firefox 51.0.1 / Twenty Seventeen theme, fresh install.

The site was under a .dev domain. The site has an IDN (Example: xn--hellthere-37a.dev )

[westonruter]

@khromov please provide more details. Are you returning a CSP response header?

[khromov]

@westonruter The iframe call to the customizer has the following response headers that might be relevant:

content-security-policy:"frame-ancestors http://xn--hellthere-37a.dev"
x-frame-options:"ALLOW-FROM http://xn--hellthere-37a.dev/wp-admin/customize.php"

The initial pageload (to load the entire customizer) has the following response header:

x-frame-options:"SAMEORIGIN"

Please let me know if you need any additional information.

[westonruter]

@khromov is the home option (frontend URL) set to be the same your siteurl option (backend WP admin URL)?

On the wordpress-develop site on VVV, the iframe document has the following response headers:

X-Frame-Options: ALLOW-FROM http://src.wordpress-develop.dev/wp-admin/customize.php
Content-Security-Policy: frame-ancestors http://src.wordpress-develop.dev

There seems to be a discrepancy between what you've pasted (e.g. additional quote marks and lower-case header names) compared to what WP on my VVV install returns. Are you sure you don't have Nginx configured to send headers of its own in addition to what WP is returning?

If you comment-out the contents of \WP_Customize_Manager::filter_iframe_security_headers() so the headers aren't sent, does the security policy still get violated?

[ABTOP]

I am having the same problem with a site hosted at Site Builder. The local installation is almost identical, except for the URL, naturally, and works fine. Firefox 51.0.1. WordPress 7.4.2

Here's the security console entry:

Content Security Policy: The page’s settings blocked the loading of a resource at http://angleškitečaj.com/wp-admin/customize.php?url=http%3A%2F%2Fxn--anglekiteaj-vnb10i.com%2F%3Fpage_id%3D417 (“frame-ancestors http://xn--anglekiteaj-vnb10i.com”).

Looks like the problem with angleškitečaj.com vs. xn--anglekiteaj-vnb10i.com