Content Security Policy
If a recorded page enforces a Content Security Policy, the policy must allow the hosts the recorder uses. A missing directive blocks the script or the event stream silently for visitors, so recordings never arrive even though your own test browser works.
Load the recorder
Loading the Browser Client from the CDN requires:
script-src https://cdn.rrweb.comInstalling @rrweb/browser-client from npm bundles the recorder with your application code, so no script-src entry is needed.
Send events
The Browser Client streams events over WebSocket and falls back to HTTP on the same host. List both schemes explicitly; some browsers do not let an https: source authorize a wss: connection:
connect-src https://api.rrweb.com wss://api.rrweb.comRecord through your own domain
When you proxy the recording endpoints and point serverUrl at your own subdomain, replace the api.rrweb.com entries with that subdomain:
connect-src https://events.my-domain.com wss://events.my-domain.comA same-origin proxy path needs no connect-src entry at all. The script-src entry is still required if the recorder script itself loads from the CDN.
Replay in your own application
These entries apply to the page that shows recordings, which is usually an internal tool with its own policy:
- Embedding the hosted player in an iframe requires
frame-src https://api.rrweb.com. - Linking screenshot images directly requires
img-src https://api.rrweb.com. - Loading
rrweb-playerand its stylesheet from the CDN requiresscript-srcandstyle-srcentries forhttps://cdn.rrweb.com.
Complete example
A recorded page that loads the recorder from the CDN and sends events to rrweb Cloud directly:
Content-Security-Policy:
script-src 'self' https://cdn.rrweb.com;
connect-src 'self' https://api.rrweb.com wss://api.rrweb.com;Merge these sources into your existing directives instead of replacing them. To verify a change safely, roll it out with Content-Security-Policy-Report-Only first and watch for violation reports before enforcing it.