fingerlydocs
fingerly.io Log inDashboard
Guides

Content Security Policy

The Content Security Policy directives the browser SDK needs: which hosts to allow, and what it never requires.

If your site sends a Content-Security-Policy header, allow the SDK to reach Fingerly. The SDK needs very little.

Directives

DirectiveAllowWhy
connect-srchttps://api.fingerly.ioIdentifications and deferred reports, both to /api/v1/ingest.
script-srcThe origin you serve the script-tag build (dist/browser.global.js) fromOnly if you use the script-tag build. A bundled import needs nothing extra.
Header
Content-Security-Policy: default-src 'self'; connect-src 'self' https://api.fingerly.io; script-src 'self'

With a proxy integration on your own origin, connect-src 'self' is enough.

What the SDK never needs

  • unsafe-eval. The SDK does not need it; under a strict policy it skips the two checks that compile code from a string. Finding that out is one blocked attempt, so if you collect CSP violation reports you will see one eval report per page load from the SDK.
  • worker-src, wasm-unsafe-eval or blob:. The SDK uses no workers and no WebAssembly.
  • Frames from other origins. The SDK only creates temporary same-origin frames, and keeps working without them if your policy forbids frames.
  • Cookies. Requests are sent without credentials, and responses set none.

CORS

Browser requests carry the x-api-key header, so browsers send a preflight first. Fingerly answers it for every origin; access is then decided by your public key's allowed origins.

Last updated