Content Security Policy
The latest preview release (EdgeHTML 15.15002) of Microsoft Edge supports Content Security Policy Level 2, which extends and replaces the original Content Security Policy (Level 1) support in the current stable public release.
The CSP security standard enables web developers to control the resources (script, CSS, plugins, images, etc.) which a particular page can fetch or execute with the aim of preventing cross-site scripting (XSS), clickjacking, and other code injection attacks seeking to execute malicious content in the context of a trusted web page. With CSP, web developers can create an allow list of sources of trusted content in the HTTP headers, pre-approving certain servers for content loaded into a webpage and instructing the browser to only execute or render resources from those sources.
Changes between CSP Level 1 and Level 2
Sites already using CSP 1 should continue to work with Microsoft Edge support for CSP 2, however it’s best to switch any
frame-src directives that load worker scripts to the new
child-src directive to future-proof your site. (In CSP 3,
frame-src will no longer apply to workers.) CSP 2 also adds the following:
plugin-types. See table below for more details.
Workers support: 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. Also new in CSP 2 is that the
allow-same-originflags of the
sandboxdirective now affect worker thread creation.
Inline scripts and styles: CSP 2 allows for the execution of inline scripts and style blocks by providing nonces and hashes as a whitelisting mechanism. Nonces are random base-64 values generated on each page load that appears in both the CSP policy and in the script tags in the page. 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. Hashes are static values generated (via sha256, sha384 or sha512 algorithms) from the content of a
<style>element that are then specified (via
style-srcdirectives) in the CSP policy.
CSP violation reporting: A new event,
SecurityPolicyViolationEventis now fired upon CSP violations. The earlier mechanism for CSP reporting,
report-uri, continues to be supported. Several new fields have been added to the violation reports common to both, including
effectiveDirective(the policy that was violated),
statusCode(the HTTP response code),
sourceFile(the URL of the offending resource),
Content-Security-Policy header value is made up of one or more directives (defined below), multiple directives are separated with a semicolon
;. The directives below are based on the Content Security Policy Level 2 specification.
|base-uri||Restricts which |
|child-src||Defines valid source for loading frames and workers.|
|connect-src||Applies to XMLHttpRequest (AJAX), WebSocket or EventSource. If not allowed the browser emulates a 400 HTTP status code.|
|font-src||Defines valid sources of fonts.|
|form-action||Restricts which |
|frame-ancestors||Restricts how the document is embedded in other documents.|
|frame-src||Deprecated. Defines valid sources for loading frames.|
|img-src||Defines valid sources of images.|
|media-src||Defines valid sources of audio and video (e.g., HTML5 |
|object-src||Defines valid sources of plugins (e.g., |
|plugin-types||Defines the plugin MIME types the document can load (e.g., |
|report-uri||Instructs the browser to POST a reports of policy failures to this URI. You can also append -Report-Only to the HTTP header name to instruct the browser to only send reports (does not block anything).|
|sandbox||Enables a sandbox for the requested resource similar to the iframe sandbox attribute. The sandbox applies a same origin policy, prevents popups, plugins and script execution is blocked. You can keep the sandbox value empty to keep all restrictions in place, or specify these values: |
|style-src||Defines valid sources of stylesheets.|
Source List Reference
All of the directives that end with
-src and also
frame-ancestors support values known as a "source list". Multiple source list values can be space separated with the exception of ‘none’ which should be the only value.
|*||img-src *||Wildcard, allows any URL except data: blob: filesystem: schemes.|
|‘none’||object-src ‘none’||Prevents loading resources from any source.|
|‘self’||script-src ‘self’||Allows loading resources from the same origin (same scheme, host and port).|
|data:||img-src ‘self’ data:||Allows loading resources via the data scheme (eg Base64 encoded images).|
|domain.foo.com||img-src img.foo.com||Allows loading resources from the specified domain name.|
|*.foo.com||img-src *.foo.com||Allows loading resources from the any subdomain under foo.com.|
|img-src ||Allows loading resources only over HTTPS matching the given domain.|
|https:||img-src https:||Allows loading resources only over HTTPS on any domain.|
|‘unsafe-inline’||script-src ‘unsafe-inline’||Allows use of inline source elements such as style attribute, onclick, or script tag bodies (depends on the context of the source it is applied to)|
Here a few common scenarios for content security policies:
Allow everything but only from the same origin
Only Allow Scripts from the same origin
Allow Google Analytics, Google AJAX CDN and Same Origin
script-src 'self' www.google-analytics.com ajax.googleapis.com;
This policy allows images, scripts, AJAX, and CSS from the same origin, and does not allow any other resources to load (eg object, frame, media, etc). It is a good starting point for many sites.
default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';
Inline script and onclick handlers
Unless explicitly whitelisted via nonce or hash (or the entire blocking mechanism is disabled via the
unsafe-inline source value), inline code and
onclick handlers are blocked from running when CSP is in effect. Whenever possible, its best to use event listeners and maintain script in a separate file from markup. For more on whitelisting inline code, see Mozilla Security Blog, CSP for the web we have.
CSP error codes and reporting blocked resources
Resources blocked by CSP are reported through F12 tools and, optionally, as a report back to the server. For a list of CSP error codes, see the Console error and status codes page of the F12 devtools guide.
For websites in a user’s trusted security zone, Microsoft Edge won’t check the MIME type of a style sheet.
Content Security Policy 1.0 *Supported on stable public release of Microsoft Edge
Content Security Policy Level 2 *Supported on preview release build EdgeHTML 15.15002+
Content Security Policy Level 3 *Not yet implemented in Microsoft Edge