> ## Documentation Index
> Fetch the complete documentation index at: https://docs.idesify.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Embedding requirements

> The CSP, permissions, and context your page must allow

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.

<Warning>
  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.
</Warning>

<AccordionGroup>
  <Accordion title="Content-Security-Policy" icon="shield">
    * `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.
  </Accordion>

  <Accordion title="Permissions-Policy" icon="camera">
    * `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.
  </Accordion>

  <Accordion title="Secure context" icon="globe">
    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.
  </Accordion>
</AccordionGroup>

```http Example headers theme={null}
Content-Security-Policy: script-src 'self' 'wasm-unsafe-eval'; worker-src 'self' blob:;
  connect-src 'self' https://api.idesify.com https://<your-media-upload-origin>;
  media-src 'self' blob:; img-src 'self' blob:
Permissions-Policy: camera=(self)
```

<Note>
  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.
</Note>

## Rights and consent widgets

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.

```http Example headers theme={null}
Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline';
  connect-src 'self' https://portal.idesify.com
```

<Note>
  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.
</Note>

## 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

<Steps>
  <Step title="Serve over HTTPS">
    Verification will not start otherwise. Test on a real staging host, not just `localhost`.
  </Step>

  <Step title="Apply the CSP and Permissions-Policy above">
    Test with the headers actually enabled. A permissive dev environment hides both failures until launch day.
  </Step>

  <Step title="Turn off debug">
    Confirm `debug` is not set in your production build.
  </Step>

  <Step title="Confirm outcomes from your backend">
    Never grant access on a browser callback alone. See [Security model](/sdk/security).
  </Step>
</Steps>