Remove object-src from the CSP (at least in MV3)

[Rob--W]

Currently, in MV2 and MV3 the CSP requires the script-src and object-src directives to be specified with secure sources only.
script-src is restricted to avoid unsafe code execution,
object-src was restricted to avoid unsafe plugin code execution (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/object-src).

These days, with plugin support having been removed from web browsers*, object-src is not useful any more.
But at least Firefox and Chrome still require object-src (or default-src as a fallback) with "secure" sources to be specified if extensions want to specify a custom CSP, despite object-src not being useful.

I propose that we remove object-src from the default CSP (which I suggested at #98 (comment)), at least in MV3. This makes the CSP more readable and makes it easier to override the custom CSP.

* Firefox is not supporting NPAPI plugins any more, including the Flash plugin.
Chrome is not supporting NPAPI plugins either, and (P)NaCl (NativeClient) have been deprecated and support is ending (https://blog.chromium.org/2020/01/moving-forward-from-chrome-apps.html). Even if there is somehow a desire to support (P)NaCl in the future, the implementation does not need to rely on CSP to block access by extensions.

[Rob--W]

There is consensus on removing object-src from the CPS.

I have filed the following issues on the individual browser repositories to track this effort:

• Firefox:https://bugzilla.mozilla.org/show_bug.cgi?id=1766881
• Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1320785

[rdcronin]

object-src applies to , , and . I think s and s can still be legitimately used for things like embedding PDFs or videos. While this isn't necessarily best practice (videos should probably be embedded with the

[rdcronin]

Wow - github apparently doesn't like it when you type HTML elements, and dropped three quarters of the comment. Trying again...

object-src applies to object, embed, and applet tags. I think object and embed tags can still be legitimately used for things like embedding PDFs or videos. While this isn't necessarily best practice (videos should probably be embedded with the video tag, for instance), I don't think this is something we'd disallow in the browser or on the platform.

Is the suggestion to remove this directive because these elements are no longer used, or because we no longer need to specify them with secure sources only? My read from this and the entry in the chromium bug tracker was the former, but I don't think that's accurate for the reason above. In theory, I think the latter may be okay - but I'm hesitant to remove this restriction until all the code to run plugins is fully removed (and I believe, as you mention, Chrome still has some support for (P)NaCl).

WDYT?

[Rob--W]

Is the suggestion to remove this directive because these elements are no longer used, or because we no longer need to specify them with secure sources only?

The suggestion is to stop requiring extensions to specify an object-src directive when they set a custom CSP. Currently, "content_security_policy": "script-src 'self'" triggers the following warning:

'content_security_policy': CSP directive 'object-src' must be specified (either explicitly, or implicitly via 'default-src') and must allowlist only secure resources.

but I'm hesitant to remove this restriction until all the code to run plugins is fully removed (and I believe, as you mention, Chrome still has some support for (P)NaCl).

If you'd still like to enforce the restriction, you could define a base policy that disallows remote sources in object-src (or "minimum" CSP to match with your description at https://crbug.com/1318922#c6). Extensions wouldn't be able to loosen the object-src policy, but at least they won't be forced to add a boilerplate object-src in the extension.

[rdcronin]

When we have a proper "minimum CSP", I'm supportive of removing this restriction. In fact, I'd be in favor of removing all restrictions - I see no reason we'd require an extension to specify something for those directives (though we could maybe warn them for directives that will be effectively ignored by our minimum?).

Until then, though, I think we'll want to keep this in place (at least on the Chrome side).

I'm also still curious for other vendor's thoughts on its presence in the minimum CSP, given it's applied to more than plugins (which is what the original post was targeting).

[xeenon]

Safari currently implicitly adds object-src 'self' if it is missing from the extension's CSP — no warning/error is given. I am supportive of dropping the requirement for object-src to be specified.

[carlosjeurissen]

@xeenon does Safari and other browsers do additional transformations besides adding object-src 'self'? Would be good to have documentation on how the browsers deal with the CSP given by the extension author.

[xeenon]

@carlosjeurissen Safari is working to change our implementation to a different parser mode in WebKit, so the current way we modify the CSP string is not a great indication on what we will do in the future.

The WebKit code can be found via: https://github.com/WebKit/WebKit/search?q=ContentSecurityPolicyModeForExtension

[Rob--W]

Marking as supportive: chrome given that the proposal here has been included in their plan shared at #98 (comment)

[Rob--W]

Implemented in Chrome 111 by https://bugs.chromium.org/p/chromium/issues/detail?id=1320785