Intent to prototype and ship: The Content-Security-Policy script-src-elem and script-src-attr directives

[Tom Schuster]

CSP 3 adds two new directives that supersede the script-src directive.
These must be honored if present, with a fallback to script-src only
if they are not present.
The attributes allow finer control for allowing scripts only in script
blocks or script attributes (event handlers).

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1529337
Standard: https://w3c.github.io/webappsec-csp/#csp-directives
Platform Coverage: all
Tests: Various web-platform-tests
Other Browsers:
- Chrome: Implemented in 79
- Safari: MDN claims this in Tech Preview

[Bobby Holley]

Hi Tom,

We don't appear to have a standards-position entry for this, which would be a prerequisite for experimenting and shipping. Could you file an issue to get that process started? Thanks.

--
You received this message because you are subscribed to the Google Groups "dev-pl...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-platform...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CA%2BCWiYia0zafa_6-65o2%2BQruiuTeB26qNntS%2B0D_asoyo5vrCw%40mail.gmail.com.

[Daniel Veditz]

Do we need separate standard positions for each feature added to CSP in level 3, or do we ask for a position on level 3 as a whole?

-Dan Veditz

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CADa3RMMXiVge5jcJ4mWyp0XATRPbdmpeBP2F6vQ-0O6Kir-Tyw%40mail.gmail.com.

[Eric Rescorla]

How many features are there in Level 3?

-Ekr

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CADYDTCBPS7n7fnp2otkR1ks8EWYK4tX%2B64xtbsw4vjUj_nCUeg%40mail.gmail.com.

[Daniel Veditz]

[resending, accidentally dropped the list]

On Wed, Jul 13, 2022 at 10:53 AM Eric Rescorla <e...@rtfm.com> wrote:

How many features are there in Level 3?

A number, most already implemented. Remaining ones are:

• This feature, adding sub-directives script-src-elem and script-src-attr. This is primarily to help legacy sites adding CSP because blocking in-line javascript is all or nothing in CSP2. (lack is notably causing web-compat issues)
  
• The 'unsafe-hashes' keyword, primarily for event handler attributes above
  
• Similarly to the first, style-src-element and style-src-attr
• Support for hash-whitelisting external scripts with integrity attributes (another web-compat sore point)
  
• the "navigate-to" directive, which we've implemented but haven't enabled. Not sure why
• the "prefetch-src" directive
• the "report-to" integration with the Reporting API ("worth prototyping")

-Dan Veditz

[Daniel Veditz]

On Fri, Jul 15, 2022 at 10:27 AM Daniel Veditz <dve...@mozilla.com> wrote:

This feature, adding sub-directives script-src-elem and script-src-attr. This is primarily to help legacy sites adding CSP because blocking in-line javascript is all or nothing in CSP2. (lack is notably causing web-compat issues)

Expanding a little on that last point in case anyone is curious:

If a site specifies the new directives a CSP3-compliant browser will ignore any "script-src" directive in that policy—it is overridden by the more specific ones. A browser without that support (e.g. Firefox) will ignore unknown directives and instead use "script-src". In theory a site can make a stricter policy for compliant browsers, and then have a weaker "combined" script-src fallback policy (that may have to have 'unsafe-inline' in it) for older browsers. Some sites either don't do the fallback, or do but don't test it in Firefox. The most common problem is adding use of script-src-attr and then taking 'unsafe-inline' out of script-src instead of adding a script-src-elem.

If you only use one of the new directives and not both together you're probably doing it wrong.

-Dan Veditz

[Bobby Holley]

So the high-order bit here is that features need a positive standards-position resolution before we ship them. The question of granularity is more of a practical consideration.

If a set of related-but-technically-independent subfeatures are all finalized, and we have the bandwidth to evaluate all of them, and we think it's reasonably likely we'll come to the same conclusion on all of them, then it's probably simplest to do them as a package. If any of those conditions doesn't hold, it may make more sense to split them up.

--

You received this message because you are subscribed to the Google Groups "dev-pl...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-platform...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CADYDTCDHhufkkbBdPgpyand%2B-7J68Zg52cPSsucee165_jHQ3Q%40mail.gmail.com.