Learning objectives
Explain the same-origin boundary; select sandbox permissions deliberately; distinguish iframe restrictions from resource CSP and Permissions Policy.
Prerequisites
Understand origins, URLs, HTML attributes, and basic JavaScript. Read the document structure lesson.
An iframe creates another document
An iframe embeds a separate browsing context inside the page. It has its own document, navigation, scripts, and potential network activity. This is useful for a trusted video player or an isolated example, but it also introduces another party’s content and behavior into the user’s experience.
Give the iframe a concise title describing the embedded content. A title such as Map of the library location is more useful than Frame. Set dimensions or an aspect-ratio layout so the page does not jump when the content loads. Loading="lazy" can defer offscreen embeds, but a lazy embed is still capable of making requests when it loads.
Understand the layers of restriction
The same-origin policy limits how documents from different origins access one another. Origin includes scheme, host, and port. Merely placing a document in an iframe does not make it untrusted or isolated from a same-origin parent.
An empty sandbox attribute enables a set of restrictions. Tokens such as allow-scripts selectively relax them. Without allow-same-origin, the sandboxed document is treated as having an opaque origin for many security checks. Combining allow-scripts and allow-same-origin for same-origin untrusted content can undermine the intended protection, because the child may be able to remove the sandbox attribute from its embedding element and reload.
Sandbox does not automatically prohibit every network request. A restrictive Content Security Policy can limit scripts, styles, images, connections, forms, and other resource types. The allow attribute controls delegated browser features through Permissions Policy; it is not an alternative spelling of sandbox. Referrerpolicy controls referrer information and does not by itself block tracking or resource loading.
Plan communication and failure
If parent and child need to communicate, postMessage can carry a structured message across origins. The receiver must check the sender’s origin and expected window, validate the message shape, and allow only specific operations. Avoid turning arbitrary messages into HTML or executable code.
A third-party site may refuse embedding through its own framing policy. Do not try to evade that decision. Provide a normal link when embedding is unavailable, and explain what the user will open. For code playgrounds, keep untrusted execution away from administrator sessions and avoid exposing privileged endpoints merely because the UI looks isolated.
Working example
<iframe title="Read-only sample document" sandbox srcdoc="<h1>Sample report</h1><p>This document has no script permissions.</p>" width="480" height="180"></iframe>Another example
<iframe title="Interactive lesson preview" src="https://preview.example.org/lesson/" sandbox="allow-scripts" referrerpolicy="no-referrer" loading="lazy" width="640" height="360"></iframe>Expected output
The first iframe renders a small read-only document when used in a normal page. The second illustrates a separately hosted preview with script permission but no same-origin permission. The learning site’s outer playground may block nested frames, so inspect this example in a local test document.
Common mistakes
Do not add every sandbox token until an embed works. Do not assume sandbox blocks fetch, or that referrerpolicy prevents all information sharing. Do not accept any postMessage event merely because it contains the expected property name.
Accessibility and browser notes
An iframe title identifies the frame, while the embedded document still needs its own accessible structure. Test keyboard entry and exit. Provide alternatives for essential information when the embedded provider is inaccessible or unavailable.
Practice
A read-only preview needs no scripts, forms, popups, or parent navigation. Write its iframe and explain which permissions you would add.
Review the solution and reasoning
<iframe title="Invoice preview" src="https://preview.example.org/invoice/" sandbox referrerpolicy="no-referrer" width="640" height="480"></iframe>The empty sandbox keeps the default restrictions. No permission token is justified by the stated requirement. The preview server should also send an appropriate CSP and avoid exposing private invoices through guessable unauthenticated URLs.