[pre-flight] Match 'self' against non-special-scheme URLs via tuple-origin components - #2
Closed
jonathanKingston wants to merge 1 commit into
Closed
jonathanKingston wants to merge 1 commit into
jonathanKingston wants to merge 1 commit into
Conversation
The 'self' fast path compares the protected resource's origin against url.origin(), but the URL standard gives every non-special-scheme URL an opaque origin - so for a document served over a scheme the user agent has registered itself, 'self' could never match even an exactly same-origin subresource, and the fallback branch only admits http(s)/ws(s). Any policy at all therefore blocked every same-origin subresource on such a document. A user agent that models those documents with tuple origins - the treatment Chromium and WebKit give schemes registered as "standard", and what makes `script-src 'self'` work on a chrome-extension:// or moz-extension:// page today - now gets component comparison: equal scheme, equal host, and equal ports, where "no port on either side" (tuple sentinel port 0, no default port for the scheme) also counts as equal. Same scheme only, and only for schemes with no default port. The existing relaxation is the http -> https/wss upgrade allowance, which is meaningful only for those schemes; extending it to a registered scheme would let 'self' in a custom://example.com document match https://example.com/. Special schemes are otherwise unaffected: a same-scheme match there was already taken by the origin-equality fast path.
jonathanKingston
force-pushed
the
self-tuple-origin
branch
from
August 24, 2026 22:13
eafc713 to
e5457bc
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pre-flight only — do not merge. This PR exists to run the fork's own CI
against the branch before it goes to
rust-ammonia/rust-content-security-policy.Merging it would put the commit on this fork's
masterand make future rebasesonto upstream messier.
The base is
ci, which is upstream master plus the fork-only workflow. The diffabove is just the patch: the workflow file is on the base side only, so it never
reaches the branch we send upstream.