# After moving Croct behind our own domain, what CSP directives are still needed?

Asked by Zofia Adamczyk on 2026-07-02. Tags: csp, security, ad-blockers.

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?](/answers/strict-csp-with-croct).

I am now tightening our Content-Security-Policy accordingly and would like to
confirm the minimal directive set. Specifically:

1. Can the Croct API origin be removed from `connect-src` entirely once all SDK
   requests are proxied?
2. 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

### Accepted answer from Bram Vandenberghe (2026-07-02)

Both answers are favorable for your policy.

1. 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.

2. `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.