Why Proctoring Runs in a Cross-Origin Iframe

What is the enclave, and why an iframe?

The ProctorLink SDK is a thin loader, about 3 KB gzipped. It does not capture anything itself. When you call it, it mounts a cross-origin iframe, the enclave, served from enclave.proctorlink.com. The camera, the session token, and the keyframe capture all live inside that frame, on an origin that belongs to ProctorLink rather than to you. Your page talks to it only through the SDK.

// In your exam page. The loader is about 3 KB gzipped.
// It mounts a cross-origin iframe (the enclave) served from
// enclave.proctorlink.com, not from your own origin.
import { ProctorLink } from '@proctorlink/sdk';

const session = ProctorLink.createSession({
  jwt: sessionJwt,            // short-lived, origin-bound session token
  sessionId,                  // session_id from your mint call
  mount: '#proctor-preview',  // where the enclave's preview sits (optional)
});

// Requests the camera against the ENCLAVE origin, not your domain.
await session.start();

Because the enclave is cross-origin, the browser treats it as a separate security context. Your page cannot read into it, and it cannot read out into your page, except through the narrow interface the SDK exposes. That single design choice is what makes the three properties below possible. If you are new to the integration as a whole, start with how to add proctoring to a web application, then come back here for why the boundary is drawn where it is. For the wider decision between an SDK, a REST API, and an LMS plugin, see proctoring SDK vs API vs LMS plugin.

Where does the session token live?

Minting is a server-to-server call. Your backend calls POST /v1/sessions with your access-token and secret-token, and those credentials never leave your server. The browser receives only the session_jwt, a short-lived token scoped to one attempt and bound to the origins you listed in allowed_origins.

// Your backend. The API key stays here and never reaches the browser.
POST /v1/sessions
access-token: <YOUR_ACCESS_TOKEN>
secret-token: <YOUR_SECRET_TOKEN>
content-type: application/json

{
  "external_user_id": "candidate-123",
  "attempt_id": "attempt-789",
  "allowed_origins": ["https://exams.yourcompany.com"]
}

// The browser receives only this: a token scoped to one attempt and
// bound to your origin. It lives inside the enclave, not your JavaScript.
{
  "session_id": "6a7b18df70e4f8ecf2597b6f",
  "session_jwt": "eyJhbGciOi...",
  "expires_at": 1786443201
}

That token then lives inside the enclave, not in your page’s JavaScript. A script running on your page, whether it is your own, a third-party tag, or something injected, cannot read it, because it sits behind the cross-origin boundary. The same goes for the camera stream: the enclave holds it, and your page never touches raw video. The split is deliberate, and it is the same split described in the web application integration guide: the API key stays server-side, the browser only ever holds a token it cannot misuse.

How the boundary keeps the score tamper-resistant

The integrity score is computed server-side only. Nothing in the browser, inside or outside the enclave, can change the verdict, which is the core anti-tamper property of the design. The cross-origin boundary reinforces it from the other direction: a candidate cannot reach the capture code or the token from your page to feed the server false data. Keyframes upload from the enclave straight to object storage through presigned URLs, so the image bytes never pass through the API or through any code the candidate controls, and only periodic stills are captured rather than continuous video, which keeps bandwidth predictable.

A candidate can still refuse the camera or close the tab. Those are recorded as signals in the report, not as a way to edit a score. For what the browser can and cannot observe in the first place, and why the extension and desktop tiers exist, read what browser-based proctoring can and cannot detect. For how the server turns those signals into a verdict a reviewer can trust, see what AI proctoring measures.

Why this design holds up

Put together, the choices reinforce one another. The API key stays on your server. The browser receives a short-lived, origin-bound token that lives inside the enclave rather than in your application state. The camera permission binds to the enclave origin, so a candidate who granted it once is not prompted again elsewhere. The integrity score is computed server-side, so the verdict cannot be edited from the exam page. Each property follows from the same cross-origin boundary rather than from a separate feature you have to configure.

If some of your exams run inside Moodle rather than your own engine, you do not wire the SDK there at all; you use the drop-in plugin covered in best Moodle proctoring plugin. Across published deployments, ProctorLink has supported more than one million proctored exam sessions (methodology note below). Full cohort sizes and outcomes are on the case studies page.