Content security policy

The directives a strict Content Security Policy needs to load the suo widget and let it search.

If your site sends a Content-Security-Policy header, the widget needs three things from it: permission to load the script, permission to call the API, and permission for the inline stylesheet in its shadow root. Nothing else — it loads no images, fonts or frames from other origins, and it needs neither 'unsafe-eval' nor a framing exception.

What to allow

Directive	Value	Why
`script-src`	`https://cdn.usesuo.com`	Only for the script-tag install. With `@suo/react` the widget is bundled into your own scripts, which `'self'` already covers.
`connect-src`	`https://api.usesuo.com`	Search requests, and the click events the widget reports back, go to the `host` you pass. Use your own API host if it differs.
`style-src`	`'unsafe-inline'`	The widget writes its stylesheet into a `<style>` element inside its shadow root, which a CSP counts as inline style. See Styles.

A policy that loads the widget from the CDN and nothing else looks like this:

Text

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.usesuo.com; connect-src 'self' https://api.usesuo.com

If you pin a version with Subresource Integrity, the integrity and crossorigin="anonymous" attributes on the script tag are all you add. See Pin a version. A CSP that uses nonces or hashes for your own scripts needs the same on the widget tag: add nonce="…" to the <script>, or list the pinned file with its integrity hash in script-src.

Styles

The widget draws inside a shadow root, so your page's styles never reach it and its styles never leak out. It carries its own stylesheet in a <style> element in that shadow root, and a CSP applies to that element: without 'unsafe-inline' in style-src the widget renders unstyled. Its markup carries no inline style attributes, and it never calls eval.

Allowing 'unsafe-inline' for styles is a much smaller concession than allowing it for scripts: it lets inline CSS apply, not inline code run. Keep script-src strict and add 'unsafe-inline' to style-src only.

If a policy with no 'unsafe-inline' for styles is a hard requirement, a style-src hash of the exact stylesheet text of a pinned widget version also works; suo does not publish those hashes yet.

When it still does not load

Open the browser console on a page that fails to show the widget. A blocked script, request or style is reported as a violation that names the directive and the blocked URL; add that origin to the matching directive above and nothing else.

The widget talks to no origin other than the host you give it, so a violation for any other address comes from your own page, not from the widget.