Windows
Windows
We are happy to introduce support for (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 , and will ship to stable builds with the Windows 10 Creators Update.
Microsoft Edge 15.15002 on the
, supported in all versions of Microsoft Edge, lets web developers lock down the resources that can be used by their web application, helping prevent attacks that remain a 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:
<script nonce="NonceToken">alert("Allowed since NonceToken is declared&quot
</script>
<script nonce="NonceToken" src="https://trustedscriptsource.com.script"></script>
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:
Content-Security-Policy: default-src 'self';
script-src 'self' https://example.com 'nonce-NonceToken'
This CSP configuration allows script to be downloaded and executed from the page’s own domain, or from . 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:
We worked closely with Chrome and the to build an interoperable implementation, and continue to work closely with the W3C on .
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 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 . 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 .
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 . Give it a try and if you run into any issues in Microsoft Edge!
― Ted Dinklocker, Program Manager, Microsoft Edge
This is available in the Insider Fast ring now starting with , and will ship to stable builds with the Windows 10 Creators Update.
Microsoft Edge 15.15002 on the
, supported in all versions of Microsoft Edge, lets web developers lock down the resources that can be used by their web application, helping prevent attacks that remain a 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:
<script nonce="NonceToken">alert("Allowed since NonceToken is declared&quot
</script><script nonce="NonceToken" src="https://trustedscriptsource.com.script"></script>
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:
Content-Security-Policy: default-src 'self';
script-src 'self' https://example.com 'nonce-NonceToken'
This CSP configuration allows script to be downloaded and executed from the page’s own domain, or from . 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. 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 to build an interoperable implementation, and continue to work closely with the W3C on .
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 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 . 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 .
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 . Give it a try and if you run into any issues in Microsoft Edge!
― Ted Dinklocker, Program Manager, Microsoft Edge