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

# Security model

> What the SDK protects, what stays on your server, and what you are responsible for

The SDK runs in the browser — an environment your users fully control. Everything below follows from treating it that way.

## Trust boundaries

<Columns cols={2}>
  <Card title="Runs in the browser" icon="window">
    Camera orchestration, framing guidance, form rendering, and encryption of captured media before it is uploaded.
  </Card>

  <Card title="Stays on the server" icon="server">
    Every decision. Liveness, document authenticity, face matching, fraud analysis, and the rules that resolve a case.
  </Card>
</Columns>

On-device detection exists to help the user take a usable photo. It reports nothing about authenticity and produces no verdict, and there is no client-side signal that predicts the outcome.

<Note>
  This is a deliberate design choice, and it works in your favor. Anything a browser could decide, a determined user could forge — so nothing that matters is decided there.
</Note>

## Credentials

| Credential | Lives where | Notes |
| - | - | - |
| API key | Your backend, only | Never ships to the browser. The SDK has no parameter that accepts one. |
| Session token | Your frontend, briefly | Short-lived, minted per session by your backend. Scoped to one flow. |
| Portal UUID | Public | Appears in your Privacy Center URL. An identifier, not a credential — it grants no access. |

<Warning>
  If an API key ever reaches a browser bundle, a public repository, or a client-side environment variable, rotate it. Treat it as compromised regardless of how briefly it was exposed.
</Warning>

### Handling session tokens

* Mint the token immediately before mounting the widget, not at page load.
* Mint it from an endpoint that authenticates the caller. An unauthenticated token endpoint hands anyone a session.
* Re-mint on `onExpire` and call `resume(newToken)`. Do not extend a token's lifetime to avoid the callback.

## Captured media

Media captured during verification is encrypted on the device before it is uploaded. You do not configure this and there are no keys for you to manage — it is why the flow needs the `connect-src` entries in [Embedding requirements](/sdk/embedding).

## What the browser callback does and does not prove

`onComplete` tells you what the user's browser was told. That is the right signal for driving your UI, and the wrong signal for granting access.

<Warning>
  Confirm the outcome from your backend before unlocking anything the verification gates. A browser callback can be replayed or tampered with by the person it describes.
</Warning>

Store the `caseId` against your user so your backend can reconcile the case, and so support can trace it later.

## Identity assertion in the privacy widgets

* **Anonymous mode** — the subject asserts their own identity or identifier. It is a claim, not a proof. That is precisely why the identity gate and the biometric step-up exist. Never action a deletion or an access request on the strength of a submitted form alone.
* **Authenticated mode** — the server binds the request to the session's subject and ignores identity fields posted from the browser, so a user cannot file a request as somebody else.

Responses on both surfaces are enumeration-safe: a request naming a subject or template that does not exist returns the same generic response as one that does. Do not build logic that infers existence from a response.

## Your responsibilities

<Steps>
  <Step title="Keep the API key server-side">
    Mint session tokens from an authenticated endpoint of your own.
  </Step>

  <Step title="Serve over HTTPS and set the headers">
    See [Embedding requirements](/sdk/embedding).
  </Step>

  <Step title="Confirm outcomes server-side">
    Never grant access on a browser callback alone.
  </Step>

  <Step title="Keep debug off in production">
    The `debug` flag is for integration troubleshooting only.
  </Step>

  <Step title="Do not log diagnostic payloads to the user">
    Error `.body` values are for your logs. Show your own message instead.
  </Step>
</Steps>

## Reporting a vulnerability

If you believe you have found a security issue in the SDK or the platform, email [**support@idesify.com**](mailto:support@idesify.com) with "Security" in the subject line. Please do not disclose details publicly until we have had a chance to respond.

Use the same address for integration questions that are not security-sensitive.