-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove object-src
from the CSP (at least in MV3)
#204
Comments
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: |
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 |
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? |
The suggestion is to stop requiring extensions to specify an
If you'd still like to enforce the restriction, you could define a base policy that disallows remote sources in |
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). |
object-src
from the CSP (at least in MV3)
Safari currently implicitly adds |
@xeenon does Safari and other browsers do additional transformations besides adding |
@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 |
Marking as |
Currently, if an extension provides a custom content security policy, we require that both script-src and object-src are specified (either explicitly or through fallbacks like default-src). Since we now apply a minimum CSP to all extension pages, this is unnecessary. Additionally, since object-src is primarily used to control plugins, its presence is somewhat misleading and noisy. With this CL, we no longer require extensions to specify object-src explicitly in MV3, and instead rely on the minimum CSP to enforce the restriction. If an extension *does* specify object-src, we still require it to be secure and disallow remotely-hosted code. Because object-src inherits from default-src if it's not specified, this also means we *will* require object-src to be explicitly specified if a non-secure default-src is used (that is, the effective value of object-src in an extension-provided CSP must either be secure or be undefined). This CL does not change the default CSP; this can be visited in a follow-up. WECG Issue: w3c/webextensions#204 Bug: 1320785 Change-Id: Ib64ab23c1f8721f433a5313e1658b0c3b0e0263f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4116239 Commit-Queue: Devlin Cronin <[email protected]> Reviewed-by: David Bertoni <[email protected]> Cr-Commit-Position: refs/heads/main@{#1086114}
Implemented in Chrome 111 by https://bugs.chromium.org/p/chromium/issues/detail?id=1320785 |
Currently, in MV2 and MV3 the CSP requires the
script-src
andobject-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
(ordefault-src
as a fallback) with "secure" sources to be specified if extensions want to specify a custom CSP, despiteobject-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.
The text was updated successfully, but these errors were encountered: