Under a Content-Security-Policy, a results page renders each constituency's statement in an `<iframe srcdoc>` — which policy applies inside that frame, and why?

## The hole inheritance closes A policy is normally attached to a document by the response that delivered it: the browser reads the `Content-Security-Policy` field lines off the response and builds the document's policy list from them. That works for anything fetched over the network — and leaves a hole for documents that were never fetched. Consider the results page. It is served with a strict policy that forbids inline script. It then writes markup into an `<iframe srcdoc>`. That frame's document has no response, no header fields and therefore, on the naive model, no policy at all. If that were true, the page could place any inline script it liked inside a `srcdoc` frame and the script would run — and so would any inline script an attacker got into the markup that the page composes. The framed-content escape is the specification's own motivating example, and inheritance is the rule that closes it. ## Which contexts inherit, and which do not The rule turns on **how the document was created**, not on whether it is same-origin with anything: | Context | Where its policy list comes from | |---|---| | A frame loaded from `https://…` | its own response's `Content-Security-Policy` field lines — empty if it has none | | `<iframe srcdoc="…">` | a copy of the creating document's list | | A document from a `blob:` URL | a copy of the creating document's list | | A document from a `data:` URL | a copy of the creating document's list | | An `about:blank` document scripted into existence | a copy of the creating document's list | | A worker created from a `blob:` URL | a copy of the creating document's list | | A worker created from `https://…` | its own response's `Content-Security-Policy` field lines | The first row is the one candidates get backwards. A frame served from a real URL does **not** inherit anything from the page that framed it. It brings whatever its own response brought, which may be nothing at all. Inheritance exists precisely for the contexts that have no response of their own. ## It is a copy, not a link The inherited list is a **snapshot taken at creation time**. Three consequences follow, and all three are asked about: 1. Changing the creating document's policy after the fact — by adding a policy in a `<meta http-equiv="Content-Security-Policy">` element, for example — does not reach a frame or worker that already exists. 2. A policy added inside the created document does not travel back to its creator. 3. Nothing about the relationship is live: there is no ongoing propagation in either direction once the copy is made. So a worker created from a `blob:` URL enforces the policies that were on its creator when it was created, for the whole of its life, regardless of what the creating document does afterwards. ## Why the list carries a self-origin A document created from a local scheme can end up in an **opaque origin** — an origin that is not equal to any other, including its creator's. That is a problem for one specific source expression: `'self'`. A keyword-source that means "the document's own origin" has nothing useful to resolve to in an opaque origin, and a policy of `script-src 'self'` inherited into such a document would match nothing at all. The CSP list therefore carries a **self-origin** alongside its policies, so that `'self'` in an inherited policy still resolves to the origin the policy came from. Note what this does not do: storing that origin does not make the created document's origin any less opaque. It exists so the inherited policy remains meaningful, not to change the document's origin. ## A policy written inside the created document A `<meta http-equiv="Content-Security-Policy">` element inside the `srcdoc` markup binds **that frame's document**. It is appended to that document's own policy list, which already holds the inherited copy, so the frame then has to satisfy both. It does not reach the parent, and it cannot loosen the inherited copy — the two are separate members of one list and each is enforced on its own terms. ## Getting it wrong - Assuming every frame inherits from its parent, and being surprised when a framed third-party document loads scripts your policy forbids. - Assuming a `srcdoc` frame is unconstrained, and shipping inline script into it. - Assuming the relationship is live, and expecting a policy tightened on the page to reach a worker already running. - Assuming an opaque-origin document silently loses `'self'`, when the stored self-origin is exactly what preserves it.