# Does Croct work under a strict Content-Security-Policy?

Asked by rhysm on 2026-05-26. Tags: security, csp, dx.

We run a strict CSP, no unsafe-inline anywhere. The last visual testing
tool we evaluated required inline script injection for its variants, which
would have forced us to punch holes in the policy, so we dropped it.

Before I spend time on a Croct proof of concept: what directives does it
actually need? Specifically whether any inline scripts or eval are involved
in how variants get applied, and which hosts need to go in script-src and
connect-src

## 1 answer

### Accepted answer from Croct Bot (2026-05-26)

Croct works under a strict CSP without unsafe-inline.

The SDK is a normal bundled npm dependency that ships with your own
application code. Variants are content served through your components,
not injected scripts, so there is no inline script injection and no
eval-based variant code. Nothing in the integration requires an
unsafe-inline or unsafe-eval exception.

The directives you need depend on the integration path:

1. With the npm SDK, the only external calls are API requests to
   `api.croct.io`, so that host goes in `connect-src`. No script-src
   changes are needed since the SDK is part of your bundle.
2. With the no-code script tag option, the script loads from
   `cdn.croct.io`, so that host goes in `script-src` in addition to the
   `connect-src` entry above.

If you prefer to keep `connect-src` same-origin, the SDK supports
[first-party proxying](https://docs.croct.com/immersion/tutorials/first-party-api-routing) via the `baseEndpointUrl` option, routing API
traffic through your own domain. In that setup no third-party hosts
appear in the policy at all.