W3cubDocs

/HTTP

CSP

Content Security Policy (CSP)

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.

CSP is designed to be fully backward compatible (except CSP version 2 where there are some explicitly-mentioned inconsistencies in backward compatibility; more details here section 1.1). Browsers that don't support it still work with servers that implement it, and vice versa: browsers that don't support CSP ignore it, functioning as usual, defaulting to the standard same-origin policy for web content. If the site doesn't offer the CSP header, browsers likewise use the standard same-origin policy.

To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header. (Sometimes you may see mentions of the X-Content-Security-Policy header, but that's an older version and you don't need to specify it anymore.)

Alternatively, the <meta> element can be used to configure a policy, for example:

<meta
  http-equiv="Content-Security-Policy"
  content="default-src 'self'; img-src https://*; child-src 'none';" />

Threats

Mitigating cross-site scripting

A primary goal of CSP is to mitigate and report XSS attacks. XSS attacks exploit the browser's trust in the content received from the server. Malicious scripts are executed by the victim's browser because the browser trusts the source of the content, even when it's not coming from where it seems to be coming from.

CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts. A CSP compatible browser will then only execute scripts loaded in source files received from those allowed domains, ignoring all other scripts (including inline scripts and event-handling HTML attributes).

As an ultimate form of protection, sites that want to never allow scripts to be executed can opt to globally disallow script execution.

Mitigating packet sniffing attacks

In addition to restricting the domains from which content can be loaded, the server can specify which protocols are allowed to be used; for example (and ideally, from a security standpoint), a server can specify that all content must be loaded using HTTPS. A complete data transmission security strategy includes not only enforcing HTTPS for data transfer, but also marking all cookies with the secure attribute and providing automatic redirects from HTTP pages to their HTTPS counterparts. Sites may also use the Strict-Transport-Security HTTP header to ensure that browsers connect to them only over an encrypted channel.

Using CSP

Configuring Content Security Policy involves adding the Content-Security-Policy HTTP header to a web page and giving it values to control what resources the user agent is allowed to load for that page. For example, a page that uploads and displays images could allow images from anywhere, but restrict a form action to a specific endpoint. A properly designed Content Security Policy helps protect a page against a cross-site scripting attack. This article explains how to construct such headers properly, and provides examples.

Specifying your policy

You can use the Content-Security-Policy HTTP header to specify your policy, like this:

Content-Security-Policy: policy

The policy is a string containing the policy directives describing your Content Security Policy.

Writing a policy

A policy is described using a series of policy directives, each of which describes the policy for a certain resource type or policy area. Your policy should include a default-src policy directive, which is a fallback for other resource types when they don't have policies of their own (for a complete list, see the description of the default-src directive). A policy needs to include a default-src or script-src directive to prevent inline scripts from running, as well as blocking the use of eval(). A policy needs to include a default-src or style-src directive to restrict inline styles from being applied from a <style> element or a style attribute. There are specific directives for a wide variety of types of items, so that each type can have its own policy, including fonts, frames, images, audio and video media, scripts, and workers.

For a complete list of policy directives, see the reference page for the Content-Security-Policy header.

Examples: Common use cases

This section provides examples of some common security policy scenarios.

Example 1

A web site administrator wants all content to come from the site's own origin (this excludes subdomains.)

Content-Security-Policy: default-src 'self'

Example 2

A web site administrator wants to allow content from a trusted domain and all its subdomains (it doesn't have to be the same domain that the CSP is set on.)

Content-Security-Policy: default-src 'self' example.com *.example.com

Example 3

A web site administrator wants to allow users of a web application to include images from any origin in their own content, but to restrict audio or video media to trusted providers, and all scripts only to a specific server that hosts trusted code.

Content-Security-Policy: default-src 'self'; img-src *; media-src example.org example.net; script-src userscripts.example.com

Here, by default, content is only permitted from the document's origin, with the following exceptions:

  • Images may load from anywhere (note the "*" wildcard).
  • Media is only allowed from example.org and example.net (and not from subdomains of those sites).
  • Executable script is only allowed from userscripts.example.com.

Example 4

A web site administrator for an online banking site wants to ensure that all its content is loaded using TLS, in order to prevent attackers from eavesdropping on requests.

Content-Security-Policy: default-src https://onlinebanking.example.com

The server permits access only to documents being loaded specifically over HTTPS through the single origin onlinebanking.example.com.

Example 5

A web site administrator of a web mail site wants to allow HTML in email, as well as images loaded from anywhere, but not JavaScript or other potentially dangerous content.

Content-Security-Policy: default-src 'self' *.example.com; img-src *

Note that this example doesn't specify a script-src; with the example CSP, this site uses the setting specified by the default-src directive, which means that scripts can be loaded only from the originating server.

Testing your policy

To ease deployment, CSP can be deployed in report-only mode. The policy is not enforced, but any violations are reported to a provided URI. Additionally, a report-only header can be used to test a future revision to a policy without actually deploying it.

You can use the Content-Security-Policy-Report-Only HTTP header to specify your policy, like this:

Content-Security-Policy-Report-Only: policy

If both a Content-Security-Policy-Report-Only header and a Content-Security-Policy header are present in the same response, both policies are honored. The policy specified in Content-Security-Policy headers is enforced while the Content-Security-Policy-Report-Only policy generates reports but is not enforced.

Enabling reporting

By default, violation reports aren't sent. To enable violation reporting, you need to specify the report-uri policy directive, providing at least one URI to which to deliver the reports:

Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi

Then you need to set up your server to receive the reports; it can store or process them in whatever manner you determine is appropriate.

Violation report syntax

The report JSON object contains the following data:

blocked-uri

The URI of the resource that was blocked from loading by the Content Security Policy. If the blocked URI is from a different origin than the document-uri, then the blocked URI is truncated to contain just the scheme, host, and port.

disposition

Either "enforce" or "report" depending on whether the Content-Security-Policy-Report-Only header or the Content-Security-Policy header is used.

document-uri

The URI of the document in which the violation occurred.

effective-directive

The directive whose enforcement caused the violation. Some browsers may provide different values, such as Chrome providing style-src-elem/style-src-attr, even when the actually enforced directive was style-src.

original-policy

The original policy as specified by the Content-Security-Policy HTTP header.

referrer Deprecated Non-standard

The referrer of the document in which the violation occurred.

script-sample

The first 40 characters of the inline script, event handler, or style that caused the violation. Only applicable to script-src* and style-src* violations, when they contain the 'report-sample'

status-code

The HTTP status code of the resource on which the global object was instantiated.

violated-directive

The name of the policy section that was violated.

Sample violation report

Let's consider a page located at http://example.com/signup.html. It uses the following policy, disallowing everything but stylesheets from cdn.example.com.

Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports

The HTML of signup.html looks like this:

<!DOCTYPE html>
<html lang="en-US">
  <head>
    <meta charset="UTF-8" />
    <title>Sign Up</title>
    <link rel="stylesheet" href="css/style.css" />
  </head>
  <body>
    Here be content.
  </body>
</html>

Can you spot the mistake? Stylesheets are allowed to be loaded only from cdn.example.com, yet the website tries to load one from its own origin (http://example.com). A browser capable of enforcing CSP would send the following violation report as a POST request to http://example.com/_/csp-reports, when the document is visited:

{
  "csp-report": {
    "document-uri": "http://example.com/signup.html",
    "referrer": "",
    "blocked-uri": "http://example.com/css/style.css",
    "violated-directive": "style-src cdn.example.com",
    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
  }
}

As you can see, the report includes the full path to the violating resource in blocked-uri. This is not always the case. For example, if the signup.html attempted to load CSS from http://anothercdn.example.com/stylesheet.css, the browser would not include the full path, but only the origin (http://anothercdn.example.com). The CSP specification gives an explanation of this odd behavior. In summary, this is done to prevent leaking sensitive information about cross-origin resources.

Browser compatibility

Desktop Mobile
Chrome Edge Firefox Internet Explorer Opera Safari WebView Android Chrome Android Firefox for Android Opera Android Safari on IOS Samsung Internet
CSP
25
14
14
23
4
10
Only supporting 'sandbox' directive.
15
7
6
Yes
Yes
23
Yes
7
6
Yes
base-uri
40
79
35
No
27
10
Yes
Yes
35
No
9.3
Yes
block-all-mixed-content
Yes
≤79
48
No
Yes
No
Yes
Yes
48
No
No
Yes
child-src
40
15
45
No
27
10
Yes
Yes
45
No
9.3
Yes
connect-src
25
14
23
Before Firefox 50, ping attributes of <a> elements weren't covered by connect-src.
No
15
7
Yes
Yes
23
No
7
Yes
default-src
25
14
23
No
15
7
Yes
Yes
23
No
7
Yes
font-src
25
14
23
No
15
7
Yes
Yes
23
No
7
Yes
form-action
40
15
36
No
27
10
Yes
Yes
36
No
9.3
Yes
frame-ancestors
40
15
33
Before Firefox 58, frame-ancestors is ignored in Content-Security-Policy-Report-Only.
No
26
10
No
Yes
33
Before Firefox for Android 58, frame-ancestors is ignored in Content-Security-Policy-Report-Only.
No
9.3
Yes
frame-src
25
14
23
No
15
7
Yes
Yes
23
No
7
Yes
img-src
25
14
23
No
15
7
Yes
Yes
23
No
7
Yes
manifest-src
Yes
79
41
No
Yes
No
Yes
Yes
41
No
No
Yes
media-src
25
14
23
No
15
7
Yes
Yes
23
No
7
Yes
meta-element-support
Yes
≤18
45
No
Yes
Yes
Yes
Yes
45
Yes
Yes
Yes
navigate-to
No
No
No
No
No
No
No
No
No
No
No
No
object-src
25
14
23
No
15
7
Yes
Yes
23
No
7
Yes
plugin-types
40-90
15-90
No
No
27-76
10
Yes-90
Yes-90
No
No
9.3
Yes-15.0
prefetch-src
No
No
No
No
No
No
No
No
No
No
No
No
referrer
33-56
No
37-62
No
Yes-43
No
4.4.3-56
33-56
37-62
Yes-43
No
2.0-6.0
report-sample
59
≤79
No
No
46
15.4
59
59
No
43
15.4
7.0
report-to
70
79
No
No
No
No
70
70
No
No
No
10.0
report-uri
25
14
23
No
15
7
Yes
Yes
23
No
7
Yes
require-sri-for
54
79
No
No
41
No
54
54
No
41
No
6.0
require-trusted-types-for
83
83
No
No
69
No
83
83
No
59
No
13.0
sandbox
25
14
50
10
15
7
Yes
Yes
50
No
7
Yes
script-src
25
14
23
No
15
7
Yes
Yes
23
No
7
Yes
script-src-attr
75
79
No
No
62
preview
75
75
No
No
No
11.0
script-src-elem
75
79
No
No
62
preview
75
75
No
No
No
11.0
strict-dynamic
52
79
52
No
39
15.4
52
52
No
41
15.4
6.0
style-src
25
14
23
No
15
7
Yes
Yes
23
No
7
Yes
style-src-attr
75
79
No
No
62
preview
75
75
No
No
No
11.0
style-src-elem
75
79
No
No
62
preview
75
75
No
No
No
11.0
trusted-types
83
83
No
No
69
No
83
83
No
No
No
13.0
unsafe-hashes
69
79
No
No
56
15.4
69
69
No
48
15.4
10.0
upgrade-insecure-requests
43
17
42
No
30
10.1
43
43
42
30
10.3
4.0
worker-src
59
Chrome 59 and higher skips the deprecated child-src directive.
79
58
No
48
15.5
59
Chrome 59 and higher skips the deprecated child-src directive.
59
Chrome 59 and higher skips the deprecated child-src directive.
58
45
15.5
7.0
worker_support
Yes
≤79
50
No
No
10
Yes
Yes
50
No
10
Yes

Compatibility notes

A specific incompatibility exists in some versions of the Safari web browser, whereby if a Content Security Policy header is set, but not a Same Origin header, the browser will block self-hosted content and off-site content, and incorrectly report that this is due to the Content Security Policy not allowing the content.

See also

© 2005–2022 MDN contributors.
Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP