# Content Security Policy

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

Last updated: 2026-09-17

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

## Directives

| Directive | Allow | Why |
| --- | --- | --- |
| `connect-src` | `https://us.api.fingerly.io` | Identify requests and deferred reports. |
| `script-src` | The origin you serve `fingerly.global.js` from | Only if you use the script-tag build. A bundled import needs nothing extra. |

```http Header
Content-Security-Policy: default-src 'self'; connect-src 'self' https://us.api.fingerly.io; script-src 'self'
```

With a [proxy integration](https://docs.fingerly.io/docs/proxy-integrations) 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 simply skips what it cannot do.
- `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.

> **Note:** The server API, `GET /events`, does not answer browsers at all. Read events from your backend.