CSP Compatibility
If your site ships a Content-Security-Policy, these are the exact directives the widget needs — and what degrades gracefully if you can't grant them.
TL;DR
Add https://askorac.com to three directives: script-src, frame-src, and connect-src. That's the complete list — the widget needs nothing else to be fully functional.
Content-Security-Policy:
script-src 'self' https://askorac.com;
frame-src 'self' https://askorac.com;
connect-src 'self' https://askorac.com;What each directive is for
script-src — loads https://askorac.com/widget.js, the embed script itself. Note that the snippet you paste is not an inline script — it loads from a remote src — so CSP modes that block inline scripts (including Wordfence's strict setting on WordPress) don't affect it.
frame-src — the chat panel renders inside an iframe served from askorac.com. This isolation is also why the widget's CSS can never conflict with your site's.
connect-src — one small fetch from your page's context retrieves the widget's configuration (colors, welcome message, position) before rendering.
Chat traffic is not your CSP's problem. Messages, streaming responses, and attachments all travel from inside the iframe — which runs under askorac.com's own origin and policy, not yours. You never need to whitelist anything for the conversation itself.
style-src — optional, degrades gracefully
The widget styles itself through the CSSOM, which CSP does not restrict. Two cosmetic features, however, inject small <style> elements into your page: the entrance animation on proactive messages, and print rules that hide the widget when a visitor prints your page.
If your style-src blocks inline styles, both features are skipped silently — the widget, chat, and all core functionality work exactly the same. If you want them, add 'unsafe-inline' to style-src; we don't consider it worth weakening your policy for, and the widget never requires it.
Platform notes
Webflow, Wix, Squarespace, most WordPress themes, and Vite/React SPAs ship no CSP by default — the widget works with zero configuration.
Shopify — standard storefronts don't restrict third-party scripts. If you've added a custom CSP via your theme or a security app, apply the three directives above.
WordPress + Wordfence (strict mode) — works out of the box because our snippet is a remote script, not inline. If you also run a CSP plugin, add the directives above.
Next.js with a strict CSP — add askorac.com to your policy in next.config.js headers or middleware. If you use nonce-based script-src, either add our origin alongside your nonce or add 'strict-dynamic'-compatible loading via your own nonced loader.
If you can't change your CSP
The widget is built to fail silently: when your policy blocks it, nothing renders and nothing breaks — no console-visible crashes, no layout shifts, no impact on your page. Your site behaves exactly as if the snippet weren't there. When you're able to update the policy, the widget appears on the next page load with no other changes.
Debugging tip: a blocked directive shows up in your browser console as a CSP violation report naming the exact directive — that message tells you precisely which line above to apply.