1490252 - Assert that referrer and triggeringPrincipal are identicial for docshell loads

Status: NEW

(Core :: DOM: Security, enhancement, P3)

Description

[Christoph Kerschbaumer [:ckerschb}]

Once we have a valid triggeringPrincipal on all docshell loads (Bug 1333030) we should make sure that the triggeringPrincipal and the referrer match.

In fact, if there is a referrer, the triggeringPrincipal should be a CodeBasePrincipal and the URI of that CodeBasePrincipals should match the referrer URI.

Let's have a look how far we are away from adding such an assertion:
 https://treeherder.mozilla.org/#/jobs?repo=try&revision=e78c1303b879641575c03f4212aff627b7bc25e9

Comment 1

[:Gijs (away/busy until Mar 10)]

Why would this always be the case? What if new document loads are triggered by a webextension but with the referrer set to the currently-loaded doc, for instance?

Comment 2

[Christoph Kerschbaumer [:ckerschb}]

(In reply to :Gijs (he/him) from comment #1)
> Why would this always be the case? What if new document loads are triggered
> by a webextension but with the referrer set to the currently-loaded doc, for
> instance?

I agree that there will be exceptions to that rule, but hopefully we can filter them out for the purpose of the assertion. What I want to make sure is that there is no misalignment of referrer and triggeringPrincipal when they in fact should match, which I would imagine is the case for a vast majority of loads.

Currently in the tree we even create the triggeringPrincpal from the referrer if no triggeringPrincipal is passed explicitly, but we hopefully should be able to remove that fallback (see Bug 1490257) soon.

Comment 3

[Jonathan Kingston [:jkt] he/him]

Try run here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=852f87901624f22cfccf56ae84f72e5123e3ccc1

Patch depends on: Bug 1508654 and Bug 1508609

Comment 4

[Jonathan Kingston [:jkt] he/him]

Attachment: Bug 1490252 - initial work for debug assert to check referrer principal matches and is codebase

Comment 5

[Jonathan Kingston [:jkt] he/him]

It seems there are a few places this might fail when in the parent process, without that I think we are more likely to land this