Does Croct work under a strict Content-Security-Policy?
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
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:
- 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.
- 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 via the baseEndpointUrl option, routing API traffic through your own domain. In that setup no third-party hosts appear in the policy at all.