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

​
Trust boundaries

Runs in the browser

Camera orchestration, framing guidance, form rendering, and encryption of captured media before it is uploaded.

Stays on the server

Every decision. Liveness, document authenticity, face matching, fraud analysis, and the rules that resolve a case.
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.
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.

​
Credentials

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.

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

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

1

Keep the API key server-side

Mint session tokens from an authenticated endpoint of your own.
2

Serve over HTTPS and set the headers

See Embedding requirements.
3

Confirm outcomes server-side

Never grant access on a browser callback alone.
4

Keep debug off in production

The debug flag is for integration troubleshooting only.
5

Do not log diagnostic payloads to the user

Error .body values are for your logs. Show your own message instead.

​
Reporting a vulnerability

If you believe you have found a security issue in the SDK or the platform, email 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.