Intent to Experiment: Extend CSP script-src (aka script-src-v2)

[Carlos IL]

Contact emails

mea...@chromium.org

Explainer

https://github.com/explainers-by-googlers/script-src-v2

Specification

https://github.com/w3c/webappsec-csp/pull/784

Summary

Introduces new keywords to the script-src Content Security Policy (CSP) directive. This adds two new hash based allowlisting mechanisms: script sources based on hashes of URLs and contents of eval() and eval() like functions. We loosely refer to this as script-src-v2, although it is backwards compatible with the existing script-src, and uses the same directive. Extending hashes to cover URL and eval() hashes allows developers to set reasonably strict security policies by narrowly allowlisting scripts by their hashes even when script contents are subject to frequent changes, and known-safe contents of eval() without permitting unchecked use of eval() broadly. The new keywords override host-based script-src when provided. This allows a single header to be compatible with browsers that both do or do not implement the new keywords.

Blink component

Blink>SecurityFeature>ContentSecurityPolicy

Web Feature ID

csp

Search tags

content security policy, csp

TAG review

https://github.com/w3ctag/design-reviews/issues/1128

TAG review status

Pending

Risks

Interoperability and Compatibility

For url hashes, the new url-<hash-algorithm>-<hash-value> keyword overrides hosts in source lists so both a host and a hash can be set. This will allow sites to enforce a stricter policy in browsers that understand the new keyword while still including a weaker policy for those that do not. This also adds a strict-dynamic-url keyword, which enables strict-dynamic like behavior when using URL hashes. This allows sites that need strict-dynamic with the new policy (but not with the fallback policy) to set it while still being able to use hostname sources in the fallback. Similarly, the new eval-<hash-algorithm>-<hash-value> keyword overrides unsafe-eval so both can be set, in order to prevent breakage for users in browsers that don't support eval hashes yet.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1277)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/535)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? None

Goals for experimentation

Ongoing technical constraints

None

Debuggability

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

YesTetntative tests have been added in https://github.com/web-platform-tests/wpt/tree/master/content-security-policy/script-src/tentative

Flag name on about://flags

None

Finch feature name

ScriptSrcHashesV1

Requires code in //chrome?

False

Tracking bug

https://crbug.com/392657736

Launch bug

https://launch.corp.google.com/launch/4394549

Estimated milestones

Origin trial desktop first	141
Origin trial desktop last	144
Origin trial Android first	141
Origin trial Android last	144
Origin trial WebView first	141
Origin trial WebView last	144

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5196368819519488?gate=5157072217571328

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANDkT5k9roBJptbJvGBCQBt1Lhefrdz3WCqvr35gHGP2aiXXJw%40mail.gmail.com