v157 · security · configuration tooling

Allowlist builder

The grammar is a structured-header list of one inner list: serialized URLPattern strings and the response-origin token, with report-to, redirects and webrtc parameters. Build one below — the page emits the exact header line, the <iframe connectionallowlist> markup and the Allow-Connection-Allowlist-From opt-in, validates it against the spec's attribute rules, exercises your patterns against real URLs with the real URLPattern engine, and runs the §4.3 satisfies comparison.

What is and is not live here: pattern matching uses this browser's genuine URLPattern implementation (probing…), and the emitted headers are exactly what the handshake lab really serves. Enforcement itself needs a build with --enable-experimental-web-platform-features (flag ConnectionAllowlistEmbeddedEnforcement); the satisfies checker is an in-page implementation of spec §4.3, labelled as such — it computes the algorithm, it does not pretend the browser enforced anything.

Build the allowlist

include the response-origin token (matches the framed response's own origin)

report-to endpoint (token, optional) redirects webrtc

report-only variant (Connection-Allowlist-Report-Only — reports, never blocks)

Emitted syntax

Response header (the framed document asserts / satisfies with this)

Embedder markup (the requirement)

Alternative opt-in: name the embedder instead of satisfying

Try a URL against the patterns (real URLPattern)

URL a framed document might fetch

Does a candidate satisfy a requirement? (spec §4.3, computed in-page)

Per the spec this is deliberately not semantic subsumption: every candidate pattern must appear, equal, in the requirement (subset by equality — this page approximates pattern-struct equality by serialized-string equality), and the candidate's redirects/webrtc must be at least as strict.

candidate (the framed response's Connection-Allowlist value) requirement (the embedder's connectionallowlist value) Not run yet.