CSP bypass plan

csp_bypass_html.md

HTML spec integration plan for WebDriver BiDi CSP bypass

Context

PR w3c/webappsec-csp#799 currently adds get-effective-csp-list checks at enforcement points in the CSP spec. Reviewers (@dveditz, @antosart) suggested a cleaner approach: have BiDi override the policy container's CSP list instead, which pushes the integration into the HTML spec and minimises (or eliminates) CSP spec changes.

---

HTML spec changes

1. create a policy container from a fetch response

Add an optional navigable-or-null parameter (default null). Skip populating the CSP list if bypass is enabled for the navigable.

To create a policy container from a fetch response given a response response,
an environment-or-null environment, and an optional navigable-or-null navigable (default null):

  ...
  Let result be a new policy container.

  If navigable is null or WebDriver BiDi CSP bypass is enabled given navigable is false:
    Set result's CSP list to the result of parsing a response's Content Security Policies given response.

  ...
  Return result.

Call sites that know the navigable (e.g. "create navigation params by fetching") pass it in. Call sites without a navigable get the default null and are unaffected.

2. clone a policy container

Same pattern — add an optional navigable-or-null and skip copying CSP policies if bypass is enabled. Covers about:blank, srcdoc, and other inherited-container cases.

To clone a policy container given a policy container policyContainer
and an optional navigable-or-null navigable (default null):

  Let clone be a new policy container.

  If navigable is null or WebDriver BiDi CSP bypass is enabled given navigable is false:
    For each policy in policyContainer's CSP list, append a copy of policy into clone's CSP list.

  Set clone's embedder policy to a copy of policyContainer's embedder policy.
  Set clone's referrer policy to policyContainer's referrer policy.
  Set clone's integrity policy to a copy of policyContainer's integrity policy.

  Return clone.

3. <meta http-equiv="Content-Security-Policy"> processing

Meta-injected CSPs bypass the fetch response path entirely, so the algorithm that appends meta CSPs to the policy container also needs a guard:

If WebDriver BiDi CSP bypass is enabled given document's node navigable is false:
  Append policy to document's policy container's CSP list.

4. Entry point for already-active navigables

When browsingContext.setBypassCSP is called on an already-created navigable, the BiDi spec clears the existing CSP list. No dedicated algorithm is needed — BiDi sets the field directly:

Set navigable's active document's policy container's CSP list to a new empty CSP list.

...and recurses over all descendant navigables.

Known gap: workers have no navigable, so they are not covered. This is consistent with how Chrome's CDP-based Page.setBypassCSP behaves today.

---

CSP spec (PR #799)

If the HTML spec route lands, almost everything in the current PR can be dropped:

• Remove get-effective-csp-list algorithm
• Remove obtain-navigable-for-request algorithm
• Revert all enforcement-point changes (redundant: an empty CSP list means no policies, so all enforcement algorithms become no-ops automatically)

The only open question is whether WebDriver BiDi CSP bypass is enabled stays as a dfn in the CSP spec (re-exported for the HTML spec to reference) or whether the HTML spec imports it directly from the BiDi spec. If the latter, the CSP spec contribution is zero and PR #799 can be closed in favour of the HTML spec PR.