Clarify object-src behavior when plugin content has no associated URL

[roberto-apple]

Given the following test case(s):

<?php
header("Content-Security-Policy: object-src 'none'", false);
//header("Content-Security-Policy: object-src;", false);
//header("Content-Security-Policy: object-src invalid;", false);
?>

<object id="obj" type="text/html"></object>
<embed id="emb" type="text/html"/>

These <object> and <embed> elements have no data/src attribute so they load no URL-associated content.
WebKit currently only blocks them under object-src 'none'

§6.1.9 (object-src) says: "If plugin content is loaded without an associated URL (perhaps an object element lacks a data attribute, but loads some default plugin based on the specified type), it MUST be blocked if object-src's value is 'none', but will otherwise be allowed."

§6.7.2.7 ("Does url match source list in origin with redirect count?") says "An empty source list (that is, a directive without a value: script-src, as opposed to script-src host1) is equivalent to a source list containing 'none', and will not match any URL."
So object-src; should also block and we are fixing this in WebKit.

However, the "but will otherwise be allowed" from 6.1.9 seems to suggest that object-src invalid; (where invalid is parsed as a hostname source expression, could've been something else) allows these elements, since the source list is not 'none'.

In contrast, Chrome blocks in this case too (object-src invalid;)

So, is the normative text in 6.1.9 intentional, or should the blocking behavior for plugin content without associated URL follow from the algorithms instead? If it's intentional, is the "but will otherwise be allowed" the correct behavior, or should any source list that cannot match the (nonexistent) URL also block?

[antosart]

I think it doesn't make sense for object-src 'none' to behave differently than object-src (empty) or object-src invalid, given §6.7.2.7 which applies to all source lists.

But also, §6.1.9 seems anyway outdated. I believe there is no hook in CSP specific to object-src (<object> and <embed> are blocked during fetch I think). And on the other hand, it seems that an <object> must always have a data attribute.

[roberto-apple]

Thanks for the response and additional context. We'll go ahead and treat §6.1.9 as obsolete in WebKit and simply adhere to §6.7.2.7, unless you (or others) see a reason not to.

[roberto-apple]

One more data point: AFAICT Chrome appears to use the document's own URL as a fallback when checking object-src for elements without a data/src attribute. This means object-src 'self' still allows them (the document URL matches 'self'), while object-src invalid; blocks (the document URL doesn't match hostname "invalid").

This is consistent with the existing WPT test object-src-no-url-allowed.html, which expects object-src 'self' to allow a URL-less <object> — that test would fail if 'self' didn't match.

Does this seem like the right approach to implement the same in WebKit?

[roberto-apple]

cc @annevk

[annevk]

Now that plugin support has mostly been removed, are there non-test scenarios where browsers still end up hitting CSP for embed or object elements without a suitable attribute? Perhaps with param elements? But if it's through param elements there would still be a URL (from that element) so it's not quite the same thing either I think.