After moving Croct behind our own domain, what CSP directives are still needed?
We recently completed a first-party proxying rollout for Croct requests, using the baseEndpointUrl and cidAssignerEndpointUrl options to route SDK traffic through our own domain. The original motivation was ad blockers filtering the default endpoints, as discussed in Does Croct work under a strict Content-Security-Policy?.
I am now tightening our Content-Security-Policy accordingly and would like to confirm the minimal directive set. Specifically:
- Can the Croct API origin be removed from connect-src entirely once all SDK requests are proxied?
- Under what circumstances does script-src still require cdn.croct.io?
We load the SDK as an npm dependency, if that is relevant to the second point.
1 answer
Both answers are favorable for your policy.
-
Yes. With baseEndpointUrl and cidAssignerEndpointUrl pointed at your own domain, every SDK request is same-origin, covered by connect-src 'self'. The Croct API origin can be removed from connect-src entirely. Worth verifying empirically after the change: browse with DevTools open and confirm no request leaves for the original API host, which also proves your proxy configuration has no gaps.
-
script-src needs cdn.croct.io only when the SDK is loaded via the no-code script tag from the CDN. Since you install it as an npm dependency, it ships inside your own application bundle and requires nothing beyond whatever already allows your first-party scripts. No inline script injection is involved either, so no unsafe-inline exception is needed on Croct's account.
So for an npm install with full first-party proxying, the minimal answer is: Croct requires no Croct-specific origins in your CSP at all. Same-origin directives cover everything.