Intent to Prototype: Extend CSP script-src (aka script-src-v2)
Mustafa Emre Acer
Contact emails
mea...@chromium.orgExplainer
https://github.com/explainers-by-googlers/script-src-v2Specification
NoneSummary
Introduces a new Content Security Policy (CSP) directive tentatively called script-src-v2. This new directive adds two new hash based allowlisting mechanisms: script sources based on hashes of URLs and contents of eval() and eval() like functions. 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. script-src-v2 drops some features considered unsafe from script-src. In particular, hostname based allowlisting functionality that is unsafe and no longer necessary given the expanded allowlisting functionality is removed. The new directive overrides script-src when provided.
Blink component
Blink>SecurityFeature>ContentSecurityPolicyMotivation
Allowlist script-src URLs with their hashes with a new keyword called url-hashes: Sites that want to allowlist scripts for use with script-src currently have 2 options: allowlist script contents through subresource integrity, which is not practical for scripts that change often (e.g. analytics), or use host-source to allowlist entire hostnames (thus allowlisting more than may be necessary). This proposal permits allowlisting full URLs, which permits precise allowlist targeting while still allowing content to change as needed. Using hashes over raw URLs in the policy allows for a more succinct representation when allowlisting longer URLs. More safely enabling scripts for use with eval(), Function, setTimeout, setInterval, and setImmediate: The only existing mechanism to use eval() and eval-like functions is by enabling them without restriction via unsafe-eval. This means that currently any site that needs to use eval() (such as for feature detection) must expose itself to eval-based XSS risks. Allowlisting individual scripts mitigates these issues. Introducing the script-src-v2 directive: Relying on the functionality above without incurring breakage on browsers that do not yet support the updated semantics necessitates a new directive that overrides the previous directive, allowing older browsers to fall back on a less-safe script-src-based policy.
Initial public proposal
https://github.com/WICG/proposals/issues/203Search tags
content security policy, cspTAG review
NoneTAG review status
PendingRisks
Interoperability and Compatibility
The new script-src-v2 directive (final name TBD) is intended to override script-src. This will allow sites to enforce a stricter policy in browsers that understand the new directive while still including a weaker policy for those that only support script-src. The new url-hashes keyword and support for hashes of eval'ed functions are only supported in script-src-v2. We decided not to backport these changes to script-src to avoid potential breakage: Sites deploying these features without checking browser support may cause the user's browser to block loading of scripts allowlisted by url-hashes and eval hashes.
Gecko: No signal
WebKit: No signal
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
Debuggability
Is this feature fully tested by web-platform-tests?
NoWeb Platform Tests will be written as part of the prototype.
Flag name on about://flags
NoneFinch feature name
CSPScriptSrcV2Requires code in //chrome?
FalseTracking bug
https://crbug.com/392657736Estimated milestones
No milestones specified