Esta traducción está incompleta. Por favor, ayuda a traducir este artículo del inglés.

Content Security Policy (CSP) es una capa de seguridad adicional que ayuda a prevenir y mitigar algunos tipos de ataque, incluyendo Cross Site Scripting (XSS) y ataques de inyección de datos. Estos ataques son usados con diversos propósitos, desde robar información hasta desfiguración de sitios o distribución de malware .

CSP está diseñado para ser completamente retrocompatible (excepto la versión 2 de CSP, donde hay algunas menciones explícitas de inconsistencia en la retrocompatibilidad; más detalles aquí sección 1.1).  Los navegadores que no lo soportan siguen funcionando con los servidores que lo implementan y viceversa: los navegadores que no soportan CSP simplemente lo ignoran, funcionando como siempre y delegando a la política mismo-origen para contenido web. Si el sitio web no ofrece la cabecera CSP, los navegadores igualmente usan la política estándar mismo-origen.

Para habilitar CSP, necesitas configurar tu servidor web para que devuelve la cabecera HTTP Content-Security-Policy (en ocasiones verás menciones de la cabecera X-Content-Security-Policy, pero se trata de una versión antigua y no necesitas especificarla más).

Alternativamente, el elemento <meta> puede ser usado para configurar una política, por ejemplo: <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">


Mitigating cross site scripting

A primary goal of CSP is to mitigate and report XSS attacks. XSS attacks exploit the browser's trust of 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 whitelisted domains, ignoring all other script (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 flag 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 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.

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 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; script-src

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

  • Images may loaded from anywhere (note the "*" wildcard).
  • Media is only allowed from and (and not from subdomains of those sites).
  • Executable script is only allowed from

Example 4

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

Content-Security-Policy: default-src

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

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' *; 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

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

Violation report syntax

The report JSON object contains the following data:

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.
Either "enforce" or "reporting" depending on whether the Content-Security-Policy-Report-Only header or the Content-Security-Policy header is used.
The URI of the document in which the violation occurred.
The directive whose inforcement caused the violation.
The original policy as specified by the Content-Security-Policy HTTP header.
The referrer of the document in which the violation occurred.
The first 40 characters of the inline script, event handler, or style that caused the violation.
The HTTP status code of the resource on which the global object was instantiated.
The name of the policy section that was violated.

Sample violation report

Let's consider a page located at It uses the following policy, disallowing everything but stylesheets from
Content-Security-Policy: default-src 'none'; style-src; report-uri /_/csp-reports
The HTML of signup.html looks like this:
<!DOCTYPE html>
    <title>Sign Up</title>
    <link rel="stylesheet" href="css/style.css">
    ... Content ...
Can you spot the mistake? Stylesheets are only allowed to be loaded from, yet the website tries to load one from its own origin ( A browser capable of enforcing CSP will send the following violation report as a POST request to, when the document is visited:
  "csp-report": {
    "document-uri": "",
    "referrer": "",
    "blocked-uri": "",
    "violated-directive": "style-src",
    "original-policy": "default-src 'none'; style-src; 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, when the signup.html would attempt to load CSS from, the browser would not include the full path but only the origin ( The CSP specification gives an explanation of this odd behaviour. In summary, this is done to prevent leaking sensitive information about cross-origin resources.

Browser compatibility

FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
base-uri40 No35 No2710
block-all-mixed-content Si ?48 No Si ?
child-src401545 No2710
connect-src2514236 No157
default-src251423 No157
disown-opener No No No No No No
font-src251423 No157
form-action401536 No2710
frame-ancestors4015337 No2610
frame-src251423 No157
img-src251423 No157
manifest-src Si No41 No Si No
media-src251423 No157
navigation-to No No No No No No
object-src251423 No157
plugin-types4015 No9 No2710
referrer33 — 56 No3710 No Si — 43 No
report-sample59 ? ? ?46 ?
report-to No No No No No No
report-uri251423 No157
require-sri-for54 No4911 No41 No
script-src251423 No157
strict-dynamic52 No52 No39 No
style-src251423 No157
upgrade-insecure-requests43 No1242 No30 No
worker-src5913 No58 No48 No
FeatureAndroid webviewChrome para AndroidEdge mobileFirefox para AndroidOpera AndroidiOS SafariSamsung Internet
Content-Security-Policy Si Si Si23 ?7.15 Si
base-uri Si Si No35 ?9.3 Si
block-all-mixed-content Si Si ?48 ? ? Si
child-src Si Si No45 ?9.3 Si
connect-src Si Si ?23 ?7.1 Si
default-src Si Si ?23 ?7.1 Si
disown-opener No No No No No No No
font-src Si Si ?23 ?7.1 Si
form-action Si Si No36 ?9.3 Si
frame-ancestors ? Si No338 ?9.3 Si
frame-src Si Si ?23 ?7.1 Si
img-src Si Si ?23 ?7.1 Si
manifest-src Si Si No41 ? No Si
media-src Si Si ?23 ?7.1 Si
navigation-to No No No No No No No
object-src Si Si ?23 ?7.1 Si
plugin-types Si Si No No ?9.3 Si
referrer33 — 5633 — 56 No3710 Si — 43 No Si
report-sample5959 ? ?46 ?7.0
report-to No No No No No No No
report-uri Si Si ?23 ?7.1 Si
require-sri-for5454 No491141 No6.0
sandbox Si Si ?50 ?7.1 Si
script-src Si Si ?23 ?7.1 Si
strict-dynamic5252 No No39 No6.0
style-src Si Si ?23 ?7.1 Si
upgrade-insecure-requests4343 No4230 No4.0
worker-src59135913 No5848 No7.0

1. Implemented as X-Webkit-CSP header in Chrome 14.

2. Implemented as X-Content-Security-Policy header in Firefox 4.

3. Implemented as X-Content-Security-Policy header, only supporting 'sandbox' directive.

4. Implemented as X-Webkit-CSP header in Safari 6.

5. Implemented as X-Webkit-CSP header in iOS 5.1.

6. Prior to Firefox 50, ping attributes of <a> elements weren't covered by connect-src.

7. Before Firefox 58, frame-ancestors is ignored in Content-Security-Policy-Report-Only.

8. Before Firefox for Android 58, frame-ancestors is ignored in Content-Security-Policy-Report-Only.

9. See Bugzilla bug 1045899.

10. Will be removed, see Bugzilla bug 1302449.

11. From version 49: this feature is behind the security.csp.experimentalEnabled preference (needs to be set to true). To change preferences in Firefox, visit about:config.

12. Under consideration for future release.

13. Chrome 59 and higher skips the deprecated child-src directive.

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 a the Content Security Policy not allowing the content.

See also

Etiquetas y colaboradores del documento

Colaboradores en esta página: vk496, CarlosRomeroVera
Última actualización por: vk496,