Make WordPress Core

Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#38571 closed defect (bug) (invalid)

Customizer preview blocked by content security policy

Reported by: rahilwazir's profile rahilwazir Owned by: rahilwazir's profile rahilwazir
Milestone: Priority: normal
Severity: normal Version:
Component: Customize Keywords: reporter-feedback
Focuses: Cc:


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

Change History (9)

#1 @westonruter
8 years ago

  • Owner set to rahilwazir
  • Status changed from new to assigned

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.

#2 @westonruter
8 years ago

@rahilwazir any update on your investigations?

This ticket was mentioned in Slack in #core by helen. View the logs.

8 years ago

#4 @westonruter
8 years ago

  • Milestone 4.7 deleted
  • Resolution set to invalid
  • Status changed from assigned to closed

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

#5 @khromov
7 years ago

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: )

#6 @westonruter
7 years ago

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

#7 @khromov
7 years ago

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


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


Please let me know if you need any additional information.

#8 @westonruter
7 years ago

@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
Content-Security-Policy: frame-ancestors

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?

7 years ago

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č (“frame-ancestors”).

Looks like the problem with angleškiteč vs.

Last edited 7 years ago by ABTOP (previous) (diff)
Note: See TracTickets for help on using tickets.