Skip to main content
Requirements differ sharply between the verification flow and the two privacy widgets. Start with the one you are embedding.

​
Verification flow

The verification flow uses the camera and runs a WebAssembly module, so the embedding page must allow all three of the following.
A missing 'wasm-unsafe-eval' in your CSP is the single most common integration failure. It fails at startup with an error that does not mention the CSP, so check this first when the flow will not start.
  • script-src and worker-src need 'wasm-unsafe-eval'.
  • connect-src must include the Idesify API origin and the media-upload origin.
  • img-src and media-src need blob: for the camera preview and captured stills.
  • camera=(self) on the top-level document.
  • If you mount the SDK inside an iframe, add allow="camera" to that frame as well. Missing this is the second most common failure.
Camera access requires HTTPS. localhost is treated as secure during development, so a flow that works locally can still fail on a staging host served over plain HTTP.
Example headers
Confirm the exact API and media-upload origins for your account in your dashboard before you pin them. They can differ by region, and a CSP pinned to the wrong origin fails only in production.
Far lighter. No camera, no engine, and no secure-context requirement.
  • Content-Security-Policy — each widget injects a scoped style element, so style-src must allow it: either 'unsafe-inline', or serve a nonce and set it on the element yourself. connect-src must include your portal origin, or whatever host your baseUrl points at.
  • Permissions-Policy — nothing required. Neither widget calls getUserMedia.
  • No 'wasm-unsafe-eval' and no worker-src entries are needed.
Example headers
If you render a CAPTCHA for the anonymous rights flow, add its origins to your CSP too. That script is yours, not ours — the SDK deliberately bundles no third-party CAPTCHA so your policy stays tight.

​
Proxying through your own domain

Every entry point accepts a baseUrl, so you can route SDK traffic through a path on your own origin instead of calling Idesify directly. If you do, point connect-src at your own host rather than ours. This is a deployment preference, not a security requirement — the SDK carries only short-lived session tokens or public identifiers, never an API key.

​
Pre-launch checklist

1

Serve over HTTPS

Verification will not start otherwise. Test on a real staging host, not just localhost.
2

Apply the CSP and Permissions-Policy above

Test with the headers actually enabled. A permissive dev environment hides both failures until launch day.
3

Turn off debug

Confirm debug is not set in your production build.
4

Confirm outcomes from your backend

Never grant access on a browser callback alone. See Security model.