Home Latest Posts Windows 10 Microsoft EdgeHTML 15 now supports Content Security Policy Level 2

Microsoft EdgeHTML 15 now supports Content Security Policy Level 2

January 14, 2017

Microsoft recently announced support for Content Security Policy Level 2 (CSP2) in Microsoft Edge. This new feature is already available for Insiders on Fast ring starting with EdgeHTML 15.15002, and will ship to stable builds when the Windows 10 Creators Update becomes available.

Screen capture of the Content Security Policy Browser Test loaded in Edge, with CSP and CSP Level 2 both passing. — Microsoft Edge 15.15002 on the CSP Browser Test

CSP2, is an effectual defense-in-depth mechanism against cross site scripting (XSS) and content injection attacks. It further builds upon Microsoft’s ongoing commitment to make Microsoft Edge the safest and most secure browser for users.

Content Security Policy, supported in all versions of Microsoft Edge, lets web developers lock down the resources that can be used by their web application, helping prevent cross-site scripting attacks that remain a common vulnerability on the web. However, the first version of Content Security Policy was difficult to implement on websites with inline script elements that either pointed to script sources or that contained script directly.
CSP2 makes these scenarios easier by adding support for nonces and hashes for script and style resources. A nonce is a cryptographically strong random value generated on each page load that appears in both the CSP policy and in the script tags in the page. Using nonces can help to minimize maintaining a list of allowed source URL values, while also allowing trusted script declared in script elements to run.

CSP2 also adds support for the following:

The new directives base-uri, child-src, form-action, frame-ancestors and plugin-types are now supported. See supported CSP directives for more.
Background worker scripts are governed by their own policy, separate from the policy of the document loading them. As with host documents, you can set the CSP for a worker in the response header.
A new event, SecurityPolicyViolationEvent, is now fired upon CSP violations. As well, several new fields have been added to the violation report object including effectiveDirective (the policy that was violated), statusCode (the HTTP response code), sourceFile (the URL of the offending resource), lineNumber, and columnNumber.