Introducing support for Content Security Policy Level 2

We are happy to introduce support for Content Security Policy Level 2 (CSP2) in Microsoft Edge, another step in our ongoing commitment to make Microsoft Edge the safest and most secure browser for our customers. CSP2, when used correctly, is an effective defense-in-depth mechanism against cross site scripting and content injection attacks.

This is available in the Insider Fast ring now starting with EdgeHTML 15.15002, and will ship to stable builds with the Windows 10 Creators Update.

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.

In order to use a nonce in an existing template based web application a developer adds a nonce token for each of the trusted inline scripts:

[code language=”html”]
<script nonce="NonceToken">alert("Allowed since NonceToken is declared")</script>
<script nonce="NonceToken" src="https://trustedscriptsource.com.script"></script>
[/code]

When the page is dynamically generated on load, the server generates a nonce value, inserts it into the NonceToken in the page and also declares it in the Content Security Policy HTTP header:

[code language=”html”]
Content-Security-Policy: default-src ‘self’;
script-src ‘self’ https://example.com ‘nonce-NonceToken’
[/code]

This CSP configuration allows script to be downloaded and executed from the page’s own domain, or from https://example.com. If a script source declaration in the page includes the correct nonce value, regardless of the source URL, that script can be downloaded and executed.

Script that does not meet these requirements would not even be downloaded by Microsoft Edge. In addition, any inline script that had the correct nonce value would be allowed to execute, but no other inline script would 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.

We worked closely with Chrome and the W3C Web Platform Tests to build an interoperable implementation, and continue to work closely with the W3C Web Application Security Working Group on Content Security Policy Level 3.

What’s next?

CSP2 is an important step for Microsoft Edge to continue to improve the security stance and defense-in-depth capabilities of web application developers, but there’s plenty still to do. Next, we’ll focus on adding support for strict-dynamic from the CSP3 spec to enable developers and site administrators to reduce their reliance on whitelists and tighten their CSP implementations.

Another CSP directive on our radar is upgrade-insecure-requests. This directive is meant to make it even easier for a site administrator to move towards using all secure transports, while avoiding having to make massive updates to URL’s in their web applications.

The work for strict-dynamic and upgrade-insecure-requests is currently under consideration for a future version of Microsoft Edge.

A more secure web is better for developers, users, and browser vendors alike, and we would love to see more web applications taking advantage of the protections that CSP offers. A good resource for thinking through an implementation is Implementing Content Security Policy. Give it a try and let us know if you run into any issues in Microsoft Edge!

― Ted Dinklocker, Program Manager, Microsoft Edge