An iframe loads a separate document. Same-origin policy limits direct DOM access across origins, while sandbox tokens and permission policy control what that document may do. These controls answer different questions: origin separation limits reads, sandbox limits actions, and permission policy limits selected browser features. None authenticates a user or authorizes access to a case. Define the embedded feature as a task with a narrow input and output before selecting frame attributes. A blocked frame must not become a blocked report.
Frame Sandbox, Capabilities, and Fallback
Working case
A supplier viewer displays one attachment for case 62. The host page sends only a short-lived attachment reference, never the full case record or a long-lived session token. The viewer needs script execution to render pages, but it does not need top-level navigation, popups, downloads, camera, or microphone. The host also exposes an ordinary link to a server-generated accessible preview. If the viewer origin is down or an enterprise policy blocks frames, reviewer 47 can still read the attachment summary and continue the report.
Implementation boundary
function viewerCapabilities(requested) {
const permitted = new Set(['allow-scripts', 'allow-same-origin']);
return requested.filter(capability => permitted.has(capability));
}
console.log(viewerCapabilities(['allow-scripts', 'allow-same-origin', 'allow-top-navigation', 'allow-downloads']).join(','));
// Output: allow-scripts,allow-same-originServe the viewer from a distinct origin when its code has a different trust owner. This viewer needs allow-scripts and allow-same-origin so messages carry its real origin; keep top-level navigation and popup powers absent. Without allow-same-origin, a sandboxed frame has an opaque origin serialized as null, so the host cannot check a specific sender origin or target that origin exactly. Never grant both script and same-origin tokens to an untrusted frame served from the host's own origin and assume the sandbox still isolates it. Set an explicit frame title, a bounded size, and a loading state with a timeout. Keep the attachment authorization on the server and expire references independently of frame lifetime. The frame load event is not proof that its content succeeded, so require a small ready message or a separate health signal before removing fallback instructions.
Cost and boundaries
Each frame is another document with network requests, script memory, layout work, and potentially separate storage. Lazy loading can defer that cost, but a frame near the current task may become late to respond. Count requests and retained memory with a realistic attachment, then cap concurrent viewers. The fallback preview costs an extra rendering path; that cost is justified only if it remains tested and available. Security review must track the exact sandbox tokens because one added token can change the power of every future viewer release.
Failure trace
The viewer changes its route after loading. The frame load event fires, but the expected page does not initialize, leaving a blank rectangle and no way forward. Another failure grants both script and same-origin powers to a same-origin frame, weakening the assumed sandbox boundary. Simulate an unavailable origin, a blocked permission, an oversized document, a malicious top-navigation attempt, and a user who cannot operate the viewer with a pointer. Check that the host keeps its own case state and that the preview link still works.
Verification
- The server rejects expired attachment references.
- Frame failure leaves a usable preview path.
- The browser blocks unapproved top-level navigation.
Practice drill
Document the viewer's exact allowed actions in a review record. Load case 62 with a valid reference and reject the same reference after expiry. Disable frame execution and use the server preview. Attempt a top-level redirect from the viewer and verify that the host does not move. Compare request and memory cost with one and four open attachments, then set a concurrency rule backed by those measurements.
Decision note
Treat the frame as an optional, separately owned capability; the host and server retain case authority.
Common Mistakes
- Treating the frame load event as successful application readiness.
- Granting every sandbox token to avoid integration work.
- Sending the full case record to a viewer that needs one attachment.
Connected lessons
Build Project: embedded attachment viewer contract and review Web Development: embedded interfaces and build integrity quiz; follow Embedded Interfaces and Cross-Window Contracts; Cross-Window Messages: Origin, Source, Schema, and Replay; MessageChannel Lifetime and Request Correlation; Popup Handoff, Return, and Window Ownership; Embedded Widget Storage and Fallback; Private Asset Downloads, Revocation, and Expiry.
