On an HTML <iframe>, what does the allow attribute control, and how is it different from the sandbox attribute?

## Two attributes, two axes Candidates routinely fuse `sandbox` and `allow` into one mental slot labelled "the iframe security attributes". They restrict different things and neither substitutes for the other. - **`sandbox`** operates on the *document's* baseline capabilities: may it run script, submit forms, open popups, navigate the top-level tab, download files, keep its real origin. It is deny-first — the attribute strips, tokens grant back. - **`allow`** operates on *powerful features* the browser gates behind permission: camera, microphone, geolocation, fullscreen, autoplay, payment, display capture, picture-in-picture, encrypted media. For a cross-origin frame these default to denied, and `allow` is how the embedder passes one down. A frame can be fully unsandboxed and still be unable to reach the camera, and a heavily sandboxed frame can still be granted fullscreen. The axes are orthogonal. ## Syntax The value is a semicolon-separated list of feature entries, each optionally followed by an allowlist: ```html <iframe src="https://meet.example/room/42" allow="camera; microphone; fullscreen; display-capture 'src'" title="Video call"></iframe> ``` The allowlist values you will see are: - `*` — any origin the frame navigates to. - `'self'` — the embedding page's own origin. - `'src'` — the origin of the frame's `src`, which is the sensible default for a third-party embed that might navigate. - `'none'` — nobody. - Explicit origins, e.g. `https://widget.example`. Writing a bare feature name (`allow="camera"`) uses the default allowlist for that entry, which is `'src'` in the attribute context. Note the quoting convention: `'self'`, `'src'` and `'none'` are written with literal single quotes inside the attribute value — a detail people get wrong when hand-writing it. ## Delegation never manufactures permission Two things a good answer states explicitly. First, `allow` **delegates**, it does not grant: if the embedding page itself does not have the feature — because the user denied it, or because the page's own environment withholds it — nothing passes down. Second, delegation is not the same as consent: the browser may still prompt the user before the frame actually gets the camera. `allow` removes the structural block, not the human decision. ## The legacy shorthands `allowfullscreen` on `<iframe>` is a boolean attribute predating the general mechanism, and it is defined as the equivalent of `allow="fullscreen"`. You will still see it in copy-pasted embed codes from video platforms, and it still works, but the modern form is a `fullscreen` entry in `allow`. If both are present the `allow` list is the one to read. ## What this attribute is not It is worth fencing the answer. `allow` on an `<iframe>` governs what the *embedded* document may use. It is not a way to grant your own page anything, it does not affect what the frame may request over the network, and it is unrelated to whether the framed site is willing to be framed at all — that is the framed site's own response-level decision, not something an embedder can assert from markup. ## A worked pairing Suppose you embed a third-party document-signing widget, served from `https://sign.example`, that needs a webcam for identity capture and needs to submit its own form: ```html <iframe src="https://sign.example/session/abc" sandbox="allow-scripts allow-forms allow-same-origin" allow="camera 'src'" referrerpolicy="strict-origin" loading="lazy" title="Document signing"></iframe> ``` Read the element as three separate decisions. `sandbox` says which baseline capabilities this document keeps — here scripting, form submission, and its own origin, which is acceptable precisely because `sign.example` is a different origin from the embedder. `allow` says which powerful feature is delegated, scoped to the frame's own origin so a navigation elsewhere loses it. `referrerpolicy`, `loading` and `title` are ordinary element attributes that have nothing to do with capability at all. Keeping those decisions distinct in your head is most of what the question is testing. ## Interview framing The likely probe after your definition is "so which one stops the frame running JavaScript?" — the answer is `sandbox`, via the absence of `allow-scripts`, and a candidate who reaches for `allow` there has the two attributes fused. The second likely probe is whether removing a feature from `allow` blocks a *same-origin* frame; by default a same-origin frame inherits the embedder's features, so the interesting control there is writing an explicit `'none'` allowlist rather than assuming omission is enough.