Elementor documents that a CSP frame-ancestors value of none can prevent the editor preview from loading and recommends self for the same-origin editor case. The effective header may come from the web server, CDN, reverse proxy, security plugin, custom code, hosting panel, or more than one layer. Adding another header can make the policy stricter or inconsistent. The repair starts by capturing the exact editor iframe URL and all response headers seen by the failing browser.
Use this when Elementor's left panel loads but the preview is blank, the console reports frame-ancestors or X-Frame-Options refusal, or the editor works on staging but fails behind a production CDN or security-header policy.
Quick answer
Open browser developer tools, identify the blocked preview iframe URL, and save the console message plus response headers. Fetch that exact URL through the public CDN and directly from the origin when possible. Inventory every source of Content-Security-Policy, Content-Security-Policy-Report-Only, and X-Frame-Options. For a same-origin Elementor editor, use a single reviewed frame-ancestors 'self' policy and compatible X-Frame-Options behavior. Do not broadly allow arbitrary external framing. Purge the changed header path and retest administrator, editor, private window, public page, and security-header scans.
What to check first
- Capture the exact editor URL, preview iframe URL, browser, role, console error, network response, redirects, and all CSP and X-Frame-Options headers.
- Compare CDN and origin headers and inspect web server, hosting, reverse proxy, Cloudflare, security plugin, mu-plugin, theme, and custom header sources.
- Check whether multiple CSP headers intersect into a stricter effective policy or whether report-only and enforced policies are being confused.
- Apply the narrow same-origin framing policy on staging, purge relevant caches, and test direct, proxied, administrator, editor, and private-window paths.
- Verify the public site still resists unintended external framing and record the security owner and review date.
Why this usually happens
- A security hardening template applies frame-ancestors none to admin and preview routes without an editor exception.
- The CDN and origin each emit a CSP header and the browser enforces their combined restrictions.
- X-Frame-Options and CSP describe different framing rules across redirects.
- A cached header survives after the server configuration is corrected.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS -I --max-time 20 'https://example.com/page/?elementor-preview=123' | grep -Ei 'content-security-policy|x-frame-options|location|cf-cache-status'
# Compare the exact iframe URL through CDN and origin, then remove duplicate header sources.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Capture the blocked iframe and effective headers | Capture the exact editor URL, preview iframe URL, browser, role, console error, network response, redirects, and all CSP and X-Frame-Options headers. | The editor preview iframe returns one coherent enforced framing policy. |
| Inventory every header source | Compare CDN and origin headers and inspect web server, hosting, reverse proxy, Cloudflare, security plugin, mu-plugin, theme, and custom header sources. | Administrator and editor roles can load, edit, preview, and publish the same fixture. |
| Consolidate the narrow same-origin policy | Check whether multiple CSP headers intersect into a stricter effective policy or whether report-only and enforced policies are being confused. | Origin, CDN, private window, and current browsers observe the same intended headers. |
| Purge CDN and browser caches | Apply the narrow same-origin framing policy on staging, purge relevant caches, and test direct, proxied, administrator, editor, and private-window paths. | An unapproved external frame is still rejected and no duplicate CSP source remains. |
Decision rule
Do not remove framing protection globally. Approve the fix only when the intended same-origin Elementor preview loads and unapproved external framing remains blocked.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| frame-ancestors none | Same-origin preview iframe | Blocked by policy |
| frame-ancestors self | Same-origin editor | Preview allowed |
| External origin | Unapproved framing site | Still blocked |
| Duplicate headers | Origin plus CDN CSP | Consolidate to one reviewed policy |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Capture the blocked iframe and effective headers
- Inventory every header source
- Consolidate the narrow same-origin policy
- Purge CDN and browser caches
- Retest editor and external framing
Production verification checklist
- The editor preview iframe returns one coherent enforced framing policy.
- Administrator and editor roles can load, edit, preview, and publish the same fixture.
- Origin, CDN, private window, and current browsers observe the same intended headers.
- An unapproved external frame is still rejected and no duplicate CSP source remains.
What to tell the client or owner
Give the owner a concise evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key logs, change made, rollback point, final result, owner, and next review date. Remove credentials and personal data before sharing it.
Mistakes to avoid
- Changing production before recording the exact version, request, UTC time, fixture, and rollback point.
- Treating one successful browser view as proof while logs, stored records, background jobs, and downstream systems remain unchecked.
- Testing a different role, cache state, locale, form, order, device, or integration path from the one users actually reach.
- Leaving debug output, temporary exclusions, test accounts, broad permissions, or helper code active after the verification window.
Questions teams ask during testing
Should I test this directly in production?
Start with read-only evidence and reproduce on staging when the change affects code, security, checkout, forms, indexing, or permissions. If production is required, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Repeat the same fixture with the same versions, URL, role, locale, cache state, and downstream integration. Compare stored evidence and logs instead of relying on a visual impression.
What evidence should I keep?
Keep UTC time, exact versions, URL or record ID, expected result, actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials and personal data.
When should I escalate?
Escalate when the site is unavailable, security scope is unclear, checkout or lead capture is affected, several systems disagree, or the next action could destroy evidence.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP repair Elementor security headers.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references