I am not sure if the problem was introduced within 965637 or pre-existing. It's very corner-casy and in any case not worth the uplift. However we should fix, because it seems 'self' on an srcdoc iframe translates to about:srcdoc instead of the parent document's URI.

Boris, it seems that for srcdoc iframes a CSP using the keyword 'self' does not translate correctly. Namely 'self' would translate to about:srcdoc while in fact should translate to the including context. I thought that instead of calling

mSelfURI = aDocument->GetDocumentURI();

I would expose something like the following on the Document:

nsIURI* GetFirstNonSrcDocDocumentURI() const {
if (mIsSrcdocDocument && mParentDocument) {
return mParentDocument->GetFirstNonSrcDocDocumentURI();
}
return mDocumentURI;
}

and then simply call:

mSelfURI = aDocument->GetFirstNonSrcDocDocumentURI();

whenever we set the RequestContext (see [0]).

But it seems that mParentDocument is not hooked up correctly at the time we call SetRequestContextWithDocument() within ::InitCSP() (see [1]) because at the time of InitCSP() the document is not done with it's initialization.

Any suggestions for a workaround?

One potential workaround:
Within the CSP code I could query the docshell from the document and then check docshell->mCurrentURI, and if it is about:srcdoc I keep going to the parent docshell. Would that be acceptable or a bad idea?

[0] https://searchfox.org/mozilla-central/source/dom/security/nsCSPContext.cpp#712
[1] https://searchfox.org/mozilla-central/source/dom/base/Document.cpp#3125

while in fact should translate to the including context

I'd think it should translate to whatever 'self' meant in the including context, if I read the CSP spec correctly.

For example, if you have a document with a blob: URL that contains a srcdoc iframe, 'self' should refer to the place where the blob: URL came from, no? Or more interesting, a data: URL that contains a srcdoc iframe: 'self' should refer to the place where the data: URL came from (which is not same-origin with either the data: document or the srcdoc document). And in fact the CSP for the data: should refer to the same thing (the place the data: came from) when it uses 'self'.

More generally, the spec associates https://w3c.github.io/webappsec-csp/#policy-self-origin with each policy, and those policies are what gets inherited along our equivalent of loadinfo CSP inheritance, along with whatever their self-origins were at the time. I guess we do the serialize-and-reparse thing, which loses the self-origin information? Could we change our serialization to include the self-origin as needed?

I'm happy to also discuss various ways of getting the "parent document for a srcdoc iframe" thing, but it seems at first glance that that does not solve the data: problem and is generally not a good match for the spec's model here...

Sorry, for all the confusion but what I tried to explain has nothing to do with CSP inheritance. It's the fact that if an srcdoc iframe creates a Meta CSP using the keyword 'self' then self does not translate correctly. Everything inheritance related works just fine and 'self' translates correctly for those cases. I wrote a patch and a testcase, let me flag you for review then the problem becomes clearer.

if an srcdoc iframe creates a Meta CSP using the keyword 'self' then self does not translate correctly

Ah, I see. OK, so what's supposed to happen here per spec is that we land in https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-content-security-policy which calls into https://w3c.github.io/webappsec-csp/#parse-serialized-policy and then that's it. At no point does it set the self-origin of the policy.

Compare this to https://w3c.github.io/webappsec-csp/#set-response-csp-list which does the parsing via https://w3c.github.io/webappsec-csp/#abstract-opdef-parse-a-serialized-csp-list (which calls https://w3c.github.io/webappsec-csp/#abstract-opdef-parse-a-serialized-csp on each comma-separated thing) and then sets a self-origin on the policy...

That said, I don't understand how https://w3c.github.io/webappsec-csp/#csp-header (which just does the parse and does not set self-origin) interacts with any of this. Is that part of the spec meant to be informative? But it's using "MUST". And if it's normative, how does it fit into the processing model? Seems to me that given that fetch calls into https://w3c.github.io/webappsec-csp/#set-response-csp-list from https://fetch.spec.whatwg.org/#main-fetch step 10, that's the actual processing model and the text in https://w3c.github.io/webappsec-csp/#csp-header should be removed or changed to be informative...

Anyway, the upshot is that as the spec is currently written <meta> policies don't have a defined self-origin. We should fix that in the spec, and in any case I'd need to see the definition for what it should be before I can propose a sane way of getting at it in Gecko code.

When defining it, we should make sure to consider the following case: A page window.opens a blob: or data: page, then navigates itself to a different origin, then the blob: or data: inserts a <meta csp>. What should the self-origin for that <meta csp> be and why?

Thanks Boris for the detailed description. I filed https://github.com/w3c/webappsec-csp/issues/405 using your detailed information. Let's see how that progresses. I'll keep an eye on it.

Putting this one back in the backlog, we have some higher priority work to finish...