Understanding Cross-Domain CSP When Embedding ZenCommunity Pro
If you have followed the previous tutorial and installed ZenCommunity Pro on a dedicated subdomain, you are already thinking about your infrastructure in the right way. But there is one more piece of the puzzle that catches many WordPress site owners completely off guard — and it has nothing to do with the plugin itself.
It is called Content Security Policy, and without understanding it, your ZenCommunity live chat widget will simply not appear on your main site. No error message. No warning. Just silence.
What Is Content Security Policy?
Content Security Policy — commonly abbreviated to CSP — is a security standard built into every modern web browser. It works by allowing a web server to declare, via HTTP headers, exactly which external sources a page is permitted to load resources from.
Think of it as a strict guest list at the door of your website. The browser is the bouncer. If a resource — a script, a connection, an embedded frame — does not appear on the approved list, the browser refuses to load it. Quietly, without drama, and without telling your visitor why.
This is by design. CSP exists to protect your visitors from a specific category of attack known as Cross-Site Scripting, or XSS — where malicious code from an unauthorised external source is injected into a trusted page and executed in the visitor’s browser. By declaring in advance exactly which sources are permitted, CSP makes it significantly harder for an attacker to inject and run unauthorised code, even if they find another vulnerability to exploit.
So yes — CSP absolutely does limit what hackers can do. A well-configured CSP policy is one of the most effective front-line defences a website can have against code injection attacks. It does not replace other security measures, but it substantially raises the barrier for anyone attempting to interfere with your site’s behaviour through the browser.
Why CSP Becomes Relevant With ZenCommunity Pro
When you embed ZenCommunity Pro’s live chat widget from community.yoursite.com into your main site at yoursite.com, the browser sees this as a cross-origin request. Your main site is asking to load and communicate with resources from a different domain — even though that domain is your own subdomain.
Without explicit CSP permission, the browser blocks it. The widget never loads. Your visitor sees nothing.
This is one of the most common reasons a cross-subdomain ZenCommunity embed appears to fail after an otherwise successful installation. The plugin is working perfectly. The embed code is correct. But the browser is enforcing its guest list and the community subdomain is not on it yet.
The Two Directives You Need to Configure
As the infographic above illustrates, CSP configuration for a cross-subdomain ZenCommunity embed requires action on both sides — your main site and your community subdomain. Fixing one without the other will leave the embed broken.
On Your Main Site — connect-src
The connect-src directive tells the browser which external URLs your page is permitted to make network connections to. For ZenCommunity’s live chat to function, your main site needs to permit two types of connection to your community subdomain:
https://community.yoursite.com— for standard HTTPS requests, including loading the widget and retrieving chat historywss://community.yoursite.com— for WebSocket connections, which power the real-time messaging that makes live chat actually live
The wss:// prefix is the WebSocket equivalent of https:// — it is an encrypted, persistent connection that stays open between the browser and the server, allowing messages to flow in real time without the page needing to reload. Without explicitly permitting wss:// connections, live chat will either fail silently or fall back to a slower polling mechanism that degrades the user experience.
On Your Community Subdomain — frame-ancestors
The frame-ancestors directive tells the browser which parent domains are permitted to embed your community subdomain’s content. On your community subdomain, you need to declare that yoursite.com is an authorised parent.
Additionally — and this is a step that is easy to overlook — any X-Frame-Options headers on your community subdomain must be removed or set to permit your main domain. X-Frame-Options is an older security header that predates CSP. If it is set to SAMEORIGIN or DENY on your community subdomain, it will override your frame-ancestors directive and block the embed regardless of what your CSP says. The two headers conflict, and the stricter one wins.
Why This Is Good Practice, Not Just a Technicality
It is worth stepping back for a moment to appreciate why CSP exists and why configuring it correctly — rather than simply disabling it — is the right approach.
A common shortcut when faced with CSP-related embed failures is to set an overly permissive policy, such as allowing connections from any source using a wildcard. This solves the immediate problem but defeats the entire purpose of the policy. You have effectively removed the bouncer from the door.
A correctly configured CSP policy — one that explicitly permits your known, trusted subdomains and nothing else — gives you the best of both worlds. Your cross-domain embed works. Your visitor’s browser is protected. And any attempt by an unauthorised source to inject connections or scripts into your page will be blocked by the browser before it can cause harm.
CSP does not make your site impenetrable. No single measure does. But it meaningfully reduces the attack surface available to anyone attempting to exploit cross-site scripting vulnerabilities, and it does so at the browser level — meaning it protects your visitors even if another layer of your security is compromised.
A Real-World Example
This is a configuration we have implemented directly at ChatBizSol. Our main portal at portal.chatbizsol.com embeds the ZenCommunity live chat widget from communityhub.chatbizsol.com. Getting this working correctly required coordinated CSP configuration on both sides — connect-src permissions on the portal, and frame-ancestors with X-Frame-Options removal on the community hub.
What Happens If You Get CSP Wrong
If your CSP configuration is incorrect or incomplete, the most common symptom is a live chat widget that simply does not appear — with no visible error to the visitor. In your browser’s developer tools, however, you will find console errors referencing blocked connections or refused frames, pointing directly to the CSP directive that needs attention.
The key principle to remember is this: both sides must be configured. A correctly permissive connect-src on your main site combined with a missing frame-ancestors on your community subdomain will still result in a broken embed. CSP is a two-way handshake — both ends of the connection must agree before the browser will permit it.