How to fix iframe “refused to connect” errors in WordPress (X-Frame-Options and CSP)

If you’ve ever tried embedding a WordPress page in an iframe and encountered a “refused to connect” error, you’re likely dealing with browser security headers blocking the request.

In this case, a WordPress page needed to be embedded on a subdomain, but was blocked due to the X-Frame-Options: SAMEORIGIN header. The solution required replacing outdated iframe restrictions with a modern, scoped Content Security Policy (CSP).

Issue Background

A WordPress site needed to embed a page into a separate subdomain environment:

  • Source page: a dedicated embed page
  • Target iframe location: a subdomain-based learning platform

The iframe failed to load and browsers displayed a “refused to connect” error due to restrictive response headers.

Diagnosis

The page response included an X-Frame-Options header set to SAMEORIGIN, which prevents embedding on any domain other than the exact same origin.

  • Subdomains are treated as separate origins
  • Legacy ALLOW-FROM directives are deprecated and unsupported
  • The security plugin in use only allowed limited header options

This made it impossible to allow iframe embedding through plugin settings alone.

Resolution Steps

1. Identify the affected page

Determined which specific page needed to be embedded and scoped the solution to that page only.

2. Override the X-Frame-Options header

Used a custom PHP snippet to remove the header for the targeted page.

3. Implement a Content Security Policy

Added a CSP header using frame-ancestors to allow only the required subdomain.

4. Use a code-based approach

add_action('send_headers', function() {
    if (is_page('embed-page-slug')) {
        header_remove('X-Frame-Options');
        header("Content-Security-Policy: frame-ancestors 'self' https://example-subdomain.com;");
    }
});

5. Test iframe functionality

Confirmed the page loads correctly within the iframe and no longer triggers browser blocking.

Final Outcome

  • The page embeds successfully on the intended subdomain
  • Security headers remain intact across the rest of the site
  • No global weakening of iframe protections

If your WordPress site is blocking iframe embeds or you’re dealing with security header conflicts, Freshy can help implement a safe and modern solution.
Contact Freshy