Showing preview only (3,616K chars total). Download the full file or copy to clipboard to get everything.
Repository: w3c/webappsec-csp
Branch: main
Commit: 0051d1622636
Files: 45
Total size: 3.4 MB
Directory structure:
gitextract_6wec4yj9/
├── .github/
│ └── workflows/
│ └── auto-publish.yml
├── .gitignore
├── .pr-preview.json
├── 2/
│ ├── index.bs
│ └── published/
│ ├── 2015-02-CR.html
│ ├── 2015-07-CR.html
│ ├── 2015-08-PR.html
│ ├── 2016-11-PR.html
│ └── default.css
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── LICENSE.md
├── Makefile
├── README.md
├── WD.html
├── api/
│ └── index.bs
├── cookies/
│ ├── Makefile
│ ├── index.bs
│ └── published/
│ └── FPWD.html
├── document/
│ ├── Makefile
│ └── index.bs
├── iana/
│ ├── Makefile
│ ├── draft-west-webappsec-csp-reg-00.html
│ ├── draft-west-webappsec-csp-reg-00.txt
│ ├── draft-west-webappsec-csp-reg-01.html
│ ├── draft-west-webappsec-csp-reg-01.txt
│ ├── draft-west-webappsec-csp-reg-02.html
│ ├── draft-west-webappsec-csp-reg-02.txt
│ ├── draft-west-webappsec-csp-reg-03.html
│ ├── draft-west-webappsec-csp-reg-03.txt
│ ├── draft-west-webappsec-csp-reg-04.html
│ ├── draft-west-webappsec-csp-reg-04.txt
│ ├── draft.md
│ └── rfc7762.xml
├── index.bs
├── pinning/
│ ├── index.bs
│ └── published/
│ ├── 2015-02-FPWD.html
│ └── default.css
├── published/
│ ├── 2012-11-15-CSP-1-0-CR.html
│ ├── 2014-02-04-CSP-1-1-WD.html
│ ├── 2014-07-03-CSP-2-LCWD.html
│ ├── 2014-09-03-CSP-2-CR.html
│ ├── FPWD-2015-01.html
│ └── default.css
└── w3c.json
================================================
FILE CONTENTS
================================================
================================================
FILE: .github/workflows/auto-publish.yml
================================================
name: CI
on:
pull_request: {}
push:
branches: [main]
jobs:
main:
name: Build, Validate, and Publish
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@v2
- uses: w3c/spec-prod@v2
with:
GH_PAGES_BRANCH: gh-pages
BUILD_FAIL_ON: link-error
W3C_ECHIDNA_TOKEN: ${{ secrets.ECHIDNA_TOKEN }}
W3C_WG_DECISION_URL: https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0170.html
W3C_BUILD_OVERRIDE: |
Shortname: CSP3
Status: WD
================================================
FILE: .gitignore
================================================
index.html
================================================
FILE: .pr-preview.json
================================================
{
"src_file": "index.bs",
"type": "bikeshed",
"params": {
"force": 1
}
}
================================================
FILE: 2/index.bs
================================================
<h1>Content Security Policy Level 2</h1>
<pre class="metadata">
Status: ED
ED: https://w3c.github.io/webappsec/specs/CSP2/
TR: http://www.w3.org/TR/CSP2/
Previous Version: http://www.w3.org/TR/2014/WD-CSP2-20140703/
Previous Version: http://www.w3.org/TR/2014/WD-CSP11-20140211/
Previous Version: http://www.w3.org/TR/2012/CR-CSP-20121115/
Shortname: CSP2
Level: 2
Editor: Mike West 56384, Google Inc., mkwst@google.com
Editor: Adam Barth 39502, Google Inc., w3c@adambarth.com
Editor: Dan Veditz 41156, Mozilla Corporation, dveditz@mozilla.com
Former Editor: Brandon Sterne, formerly of Mozilla Corporation, brandon@hackmill.com
Abstract: This document defines a policy language used to declare a set of content restrictions for a web resource, and a mechanism for transmitting the policy from a server to a client where the policy is enforced.
Group: webappsec
Link Defaults: dom-core-ls (interface) event
Indent: 2
Markup Shorthands: css off
</pre>
<!--
███ ██ ██ ██████ ██ ██ ███████ ████████ ██████
██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ████ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ █████████ ██ ██ ████████ ██████
█████████ ██ ████ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██████ ██ ██ ███████ ██ ██ ██████
-->
<pre class="anchors">
type: dfn
urlPrefix: http://www.w3.org/TR/html5/
urlPrefix: document-metadata.html
text: pragma directives
urlPrefix: dom.html
text: fallback content
text: the document's address; url: the-document's-address
urlPrefix: embedded-content-0.html
text: an iframe srcdoc document
urlPrefix: browsers.html
text: active document
text: parse a sandboxing directive
text: forced sandboxing flag set
text: ascii serialization of an origin
text: auxiliary browsing context
text: browsing context
text: ancestor browsing context
text: browsing context container
text: child browsing context
text: creating a new Document object
text: navigated; url: navigate
text: nested browsing context
text: nested through; url: browsing-context-nested-through
text: opener browsing context
text: plugin document
text: sandboxed origin browsing context flag
text: sandboxing flag set
text: top-level browsing context; url: top-level-browsing-context
urlPrefix: infrastructure.html
text: fragment; url: concept-url-fragment
text: fetch
text: document base url
text: plugin
text: reflect
text: securityerror
text: mime type
text: strictly split a string
text: skip whitespace
text: collect a sequence of characters
text: space characters; url: space-character
text: javascript global environment
text: split a string on spaces
text: strip leading and trailing whitespace
text: firing; url: concept-event-fire
text: ascii case-insensitive match; url: ascii-case-insensitive
urlPrefix: links.html
text: icon; url: rel-icon
text: link type stylesheet
urlPrefix: scripting-1.html
text: the script block's source; url: the-script-block's-source
urlPrefix: webappapis.html
text: queue a task
text: task source
text: tasks; url: concept-task
text: incumbent settings object
text: relevant settings object for a script
text: responsible document
urlPrefix: http://www.w3.org/TR/cssom/
text: insert a css rule
text: parse a css declaration block
text: parse a css rule
text: parse a group of selectors
urlPrefix: http://www.w3.org/TR/url/
text: default port
text: host; url: concept-url-host
text: origin of a url; url: concept-url-origin
text: path; url: concept-url-path
text: percent decode
text: percent encode
text: port; url: concept-url-port
text: scheme; url: concept-url-scheme
text: url parser; url: concept-url-parser
text: ipv6 address; url: concept-ipv6
urlPrefix: http://www.w3.org/TR/CSS21/conform.html
text: style sheet
urlPrefix: https://tools.ietf.org/html/rfc3986
text: IPv4address; url: section-3.2.2
type: element
urlPrefix: http://www.w3.org/TR/html5/
urlPrefix: document-metadata.html
text: base; url: the-base-element
text: head; url: the-head-element
text: link; url: the-link-element
text: meta; url: the-meta-element
text: style; url: the-style-element
urlPrefix: embedded-content-0.html
text: audio; url: the-audio-element
text: embed; url: the-embed-element
text: iframe; url: the-iframe-element
text: img; url: the-img-element
text: object; url: the-object-element
text: video; url: the-video-element
text: source; url: the-source-element
text: track; url: the-track-element
urlPrefix: scripting-1.html
text: script; url: the-script-element
urlPrefix: forms.html
text: form; url: the-form-element
text: input; url: the-input-element
urlPrefix: obsolete.html
text: applet; url: the-applet-element
text: frame
urlPrefix: http://www.w3.org/TR/SVG2/struct.html
text: svg; url: SVGElement
type: element-attr
urlPrefix: http://www.w3.org/TR/html5/
urlPrefix: document-metadata.html
text: href; for: link; url: attr-link-href
text: rel; for: link; url: attr-link-rel
text: http-equiv; for: meta; url: attr-meta-http-equiv
text: content; for: meta; url: attr-meta-content
urlPrefix: links.html
text: icon; for: link; url: rel-icon
urlPrefix: embedded-content-0.html
text: type; for: object; url: attr-object-type
text: src; for: img; url: attr-img-src
text: src; for: video; url: attr-media-src
text: src; for: embed; url: attr-embed-src
text: sandbox; for: iframe; url: attr-iframe-sandbox
text: srcdoc; for: iframe; url: attr-iframe-srcdoc
text: poster; for: video; url: attr-video-poster
text: data; for: object; url: attr-object-data
urlPrefix: browsers.html
text: allow-forms; for: iframe; url: attr-iframe-sandbox-allow-forms
text: allow-pointer-lock; for: iframe; url: attr-iframe-sandbox-allow-pointer-lock
text: allow-popups; for: iframe; url: attr-iframe-sandbox-allow-popups
text: allow-top-navigation; for: iframe; url: attr-iframe-sandbox-allow-top-navigation
text: allow-scripts; for: iframe; url: attr-iframe-sandbox-allow-scripts
text: allow-same-origin; for: iframe; url: attr-iframe-sandbox-allow-same-origin
urlPrefix: forms.html
text: image; for: input; url: attr-input-type-image-keyword
text: src; for: input; url: attr-input-src
urlPrefix: obsolete.html
text: code; for: applet; url: dom-applet-code
text: archive; for: applet; url: dom-applet-archive
urlPrefix: scripting-1.html
text: src; for: script; url: attr-script-src
type: function
urlPrefix: http://www.w3.org/TR/CSS21/syndata.html
text: url(); url: uri
urlPrefix: http://www.w3.org/TR/dom/
type: attribute
text: textContent; for: Node; url: dom-node-textcontent
type: interface
text: Document; url: interface-document
type: attribute
urlPrefix: http://www.w3.org/TR/html5/
urlPrefix: dom.html
text: referrer; for: Document; url: dom-document-referrer
type: interface
urlPrefix: https://fetch.spec.whatwg.org/
text: Request
urlPrefix: http://www.w3.org/TR/url/
text: URL; url: dom-url
urlPrefix: https://heycam.github.io/webidl/
text: long; url: idl-long
urlPrefix: http://www.w3.org/TR/html5/
urlPrefix: document-metadata.html
text: HTMLStyleElement
urlPrefix: scripting-1.html
text: HTMLScriptElement
urlPrefix: http://www.w3.org/TR/dom/
text: Event
text: EventInit
type: method
urlPrefix: http://www.w3.org/TR/html5/
urlPrefix: webappapis.html
text: setTimeout(); for: WindowTimers; url: dom-windowtimers-settimeout
text: setInterval(); for: WindowTimers; url: dom-windowtimers-setinterval
</pre>
<pre class="biblio">
{
"URL": {
"authors": [ "Anne van Kesteren", "Sam Ruby" ],
"title": "URL",
"href": "http://www.w3.org/TR/url/",
"status": "WD",
"publisher": "W3C"
},
"HTML5": {
"authors": [ "Ian Hickson", "Robin Berjon", "Steve Faulkner", "Travis Leithead", "Erika Doyle Navera", "Edward O'Connor", "Silvia Pfeiffer" ],
"title": "HTML5",
"href": "http://www.w3.org/TR/html5/",
"status": "REC",
"publisher": "W3C"
},
"FIPS180": {
"title": "FIPS-180-4",
"href": "http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf"
}
}
</pre>
<!--
████ ██ ██ ████████ ████████ ███████
██ ███ ██ ██ ██ ██ ██ ██
██ ████ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ████████ ██ ██
██ ██ ████ ██ ██ ██ ██ ██
██ ██ ███ ██ ██ ██ ██ ██
████ ██ ██ ██ ██ ██ ███████
-->
<section>
<h2 id="intro">Introduction</h2>
<em>This section is not normative.</em>
This document defines Content Security Policy, a mechanism web applications
can use to mitigate a broad class of content injection vulnerabilities, such
as cross-site scripting (XSS). Content Security Policy is a declarative policy
that lets the authors (or server administrators) of a web application inform
the client about the sources from which the application expects to load
resources.
To mitigate XSS attacks, for example, a web application can declare that it
only expects to load script from specific, trusted sources. This declaration
allows the client to detect and block malicious scripts injected into the
application by an attacker.
Content Security Policy (CSP) is not intended as a first line of defense
against content injection vulnerabilities. Instead, CSP is best used as
defense-in-depth, to reduce the harm caused by content injection attacks. As
a first line of defense against content injection, server operators should
validate their input and encode their output.
There is often a non-trivial amount of work required to apply CSP to an
existing web application. To reap the greatest benefit, authors will need to
move all inline script and style out-of-line, for example into external
scripts, because the user agent cannot determine whether an inline script
was injected by an attacker.
To take advantage of CSP, a web application opts into using CSP by supplying a
<code>Content-Security-Policy</code> HTTP header. Such policies apply to the
current resource representation only. To supply a policy for an entire site,
the server needs to supply a policy with each resource representation.
<h3 id="changes-from-level-1">Changes from Level 1</h3>
This document describes an evolution of the
<a href="http://www.w3.org/TR/CSP/">Content Security Policy specification</a>.
Level 2 makes two breaking changes from Level 1, and adds support for a number
of new directives and capabilities which are summarized below:
<ol>
<li>
The following changes are backwards incompatible with the majority of
user agent's implementations of Level 2:
<ol>
<li>
The path component of a source expression is now ignored if the
resource being loaded is the result of a redirect, as described in
[[#source-list-paths-and-redirects]].
Note: Paths are technically new in Level 2, but they were already
implemented in many user agents before this revision of CSP was
completed, so noting the change here seems reasonable.
</li>
<li>
A <a>protected resource</a>'s ability to load Workers [[!WORKERS]]
is now controlled via <a><code>child-src</code></a> rather than
<a><code>script-src</code></a>.
</li>
<li>
Workers now have their own policy, separate from the <a>protected
resource</a> which loaded them. This is described in
[[#processing-model-workers]].
</li>
</ol>
</li>
<li>
The following directives are brand new in this revision:
<ol>
<li>
<a><code>base-uri</code></a> controls the <a>protected
resource</a>'s ability to specify the <a spec="HTML5">document base
URL</a>.
</li>
<li>
<a><code>child-src</code></a> deprecates and replaces
<a><code>frame-src</code></a>, controlling the <a>protected
resource</a>'s ability to embed frames, and to load Workers.
</li>
<li>
<a><code>form-action</code></a> controls the <a>protected
resource</a>'s ability to submit forms.
</li>
<li>
<a><code>frame-ancestors</code></a> controls the <a>protected
resource</a>'s ability be embedded in other documents. It is meant
to supplant the <code>X-Frame-Options</code> HTTP request header.
[[!RFC7034]]
</li>
<li>
<a><code>plugin-types</code></a> controls the <a>protected
resource</a>'s ability to load specific types of plugins.
</li>
</ol>
</li>
<li>
Individual inline scripts and stylesheets may be whitelisted via nonces
(as described in [[#source-list-valid-nonces]]) and hashes (as described
in [[#source-list-valid-hashes]]).
</li>
<li>
A {{SecurityPolicyViolationEvent}} is fired upon violations, as described
in [[#firing-securitypolicyviolationevent-events]].
</li>
<li>
A number of new fields were added to violation reports (both those POSTED
via <a><code>report-uri</code></a>, and those handed to the DOM via
{{SecurityPolicyViolationEvent}} events. These include
{{SecurityPolicyViolationEvent/effectiveDirective}},
{{SecurityPolicyViolationEvent/statusCode}},
{{SecurityPolicyViolationEvent/sourceFile}},
{{SecurityPolicyViolationEvent/lineNumber}}, and
{{SecurityPolicyViolationEvent/columnNumber}}.
</li>
<li>
Certain flags present in the <code><a>sandbox</a></code> directive now
affect Worker creation, as described in [[#sandboxing-and-workers]].
</li>
</ol>
</section>
<!--
████████ ████████ ████████ ████ ██ ██ ████ ████████ ████ ███████ ██ ██ ██████
██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██
██ ██ ██ ██ ██ ████ ██ ██ ██ ██ ██ ██ ████ ██ ██
██ ██ ██████ ██████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██████
██ ██ ██ ██ ██ ██ ████ ██ ██ ██ ██ ██ ██ ████ ██
██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ███ ██ ██
████████ ████████ ██ ████ ██ ██ ████ ██ ████ ███████ ██ ██ ██████
-->
<section>
<h2 id="key-concepts">Key Concepts and Terminology</h2>
<h3 id="terms-defined-here">Terms defined by this specification</h3>
<dl>
<dt>
<dfn export local-lt="policy">security policy</dfn>
</dt>
<dt>
<dfn export local-lt="directive">security policy directive</dfn>
</dt>
<dt>
<dfn export local-lt="directive name">security policy directive name</dfn>
</dt>
<dt>
<dfn export local-lt="directive value">security policy directive value</dfn>
</dt>
<dd>
A <strong>security policy</strong> refers to both a set of security
preferences for restrictions within which content can operate, and
to a fragment of text that codifies or transmits these preferences.
For example, the following string is a policy which restricts script
and object content:
<div class="example">
<code><a>script-src</a> 'self'; <a>object-src</a> 'none'</code>
</div>
Security policies contain a set of <strong>security policy
directives</strong> (<code><a>script-src</a></code> and
<code><a>object-src</a></code> in the example above), each responsible
for declaring the restrictions for a particular resource type, or
manipulating a specific aspect of the policy's restrictions. The list
of directives defined by this specification can be found in
[[#directives]].
Each directives has a <strong>name</strong> and a <strong>value</strong>;
<strong>value</strong> may be optional for some directives.
A detailed grammar can be found in [[#syntax-and-algorithms]].
</dd>
<dt>
<dfn export>protected resource</dfn>
</dt>
<dd>
A <a>security policy</a> is applied by a user agent to a specific
<a>resource representation</a>, known as the <strong>protected
resource</strong>. See [[#policy-delivery]] for details regarding
the mechanisms by which policies may be applied to a protected
resource.
</dd>
</dl>
<h3 id="terms-defined-by-reference">Terms defined by reference</h3>
<dl>
<dt>
<dfn>globally unique identifier</dfn>
</dt>
<dd>
Defined in
<a href="https://tools.ietf.org/html/rfc6454#section-2.3">Section 2.3 of
the Origin specification</a>. [[!RFC6454]]
NOTE: URLs which do not use hierarchical elements as naming authorities
(<code>data:</code>, for instance) have <a>origins</a> which are globally
unique identifiers.
</dd>
<dt>
<dfn>HTTP 200 response</dfn>
</dt>
<dd>
Defined in
<a href="https://tools.ietf.org/html/rfc7231#section-6.3.1">Section
6.3.1 of HTTP/1.1 -- Semantics and Content</a>. [[!RFC7231]]
</dd>
<dt>
<dfn>JSON object</dfn>
</dt>
<dt>
<dfn>JSON stringification</dfn>
</dt>
<dd>
Defined in the JSON specification. [[!RFC4627]]
</dd>
<dt>
<dfn>origin</dfn>
</dt>
<dd>
Defined by the Origin specification. [[!RFC6454]]
</dd>
<dt>
<dfn local-lt="representation">resource representation</dfn>
</dt>
<dd>
Defined in <a href="https://tools.ietf.org/html/rfc7231#section-3">Section
3 of HTTP/1.1 -- Semantics and Content</a>. [[!RFC7231]]
</dd>
<dt>
<dfn>URL</dfn>
</dt>
<dd>
Defined by [[!URL]].
</dd>
<dt><dfn>SHA-256</dfn></dt>
<dt><dfn>SHA-384</dfn></dt>
<dt><dfn>SHA-512</dfn></dt>
<dd>
These digest algorithms are defined by the NIST. [[!FIPS180]]
</dd>
</dl>
<h3 id="html-concepts">Relevant Concepts from HTML</h3>
The <{applet}>, <{audio}>, <{embed}>, <{iframe}>, <{img}>, <{link}>,
<{object}>, <{script}>, <{source}>, <{track}>, and <{video}> are defined in
[[!HTML5]].
The terms <a>auxiliary browsing contexts</a>,
<a>opener browsing context</a>, and <a>nested browsing contexts</a> are
defined in the HTML5 specification. [[!HTML5]]
A <a>plugin</a> is defined in the HTML5 specification. [[!HTML5]]
The <code><<@font-face>></code> Cascading Style Sheets (CSS) rule is defined
in the CSS Fonts Module Level 3 specification. [[!CSS3-FONTS]]
The <code>XMLHttpRequest</code> object is defined in the
<code>XMLHttpRequest</code> specification. [[!XMLHTTPREQUEST]]
The <code>WebSocket</code> object is defined in the <code>WebSocket</code>
specification. [[!WEBSOCKETS]]
The <code>EventSource</code> object is defined in the <code>EventSource</code>
specification. [[!EVENTSOURCE]]
The <dfn>runs a worker</dfn> algorithm is
<a href="http://www.w3.org/TR/workers/#run-a-worker">defined in the Web
Workers spec</a>. [[!WORKERS]]
The term <dfn>callable</dfn> refers to an object whose interface
has one or more <dfn>callers</dfn> as defined in the <a
href="http://www.w3.org/TR/2010/WD-WebIDL-20101021/#idl-callers">Web
IDL</a> specification [[!WEBIDL]].
<h3 id="grammar">Grammatical Concepts</h3>
The Augmented Backus-Naur Form (ABNF) notation used in this document is
specified in RFC5234. [[!ABNF]]
This document also uses the ABNF extension "#rule" as defined in
<a href="https://tools.ietf.org/html/rfc7230#section-7">Section 7</a>
of HTTP/1.1 -- Message Syntax and Routing. [[!RFC7230]]
The following core rules are included by reference, as defined in
<a href="https://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>
of [[!ABNF]]: <code><dfn>ALPHA</dfn></code> (letters),
<code><dfn>DIGIT</dfn></code> (decimal 0-9), <code><dfn>WSP</dfn></code>
(white space) and <code><dfn>VCHAR</dfn></code> (printing characters).
</section>
<!--
████████ ████████ ██ ████ ██ ██ ████████ ████████ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ████
██ ██ ██████ ██ ██ ██ ██ ██████ ████████ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
████████ ████████ ████████ ████ ███ ████████ ██ ██ ██
-->
<section>
<h2 id="policy-delivery">Policy Delivery</h2>
The server delivers a <a>policy</a> to the user agent via an HTTP response
header (defined in [[#content-security-policy-header-field]] and
[[#content-security-policy-report-only-header-field]]) or an HTML
<{meta}> element (defined in [[#delivery-html-meta-element]]).
<section>
<h3 id="content-security-policy-header-field">
<code>Content-Security-Policy</code> Header Field
</h3>
The <code><dfn export>Content-Security-Policy</dfn></code> header field is
the preferred mechanism for delivering a policy. The grammar is as follows:
<pre>
"Content-Security-Policy:" 1#<a>policy-token</a>
</pre>
For example, a response might include the following header field:
<div class="example">
<code>Content-Security-Policy: <a>script-src</a> 'self'</code>
</div>
A server MUST NOT send more than one HTTP header field named
<code>Content-Security-Policy</code> with a given <a>resource
representation</a>.
A server MAY send different <code>Content-Security-Policy</code>
header field values with different <a>representations</a> of the same
resource or with different resources.
Upon receiving an HTTP response containing at least one
<code>Content-Security-Policy</code> header field, the user agent
MUST <a>enforce</a> each of the policies contained in each such
header field.
</section>
<section>
<h3 id="content-security-policy-report-only-header-field">
<code>Content-Security-Policy-Report-Only</code> Header Field
</h3>
The <code><dfn export>Content-Security-Policy-Report-Only</dfn></code>
header field lets servers experiment with policies by monitoring (rather
than enforcing) a policy. The grammar is as follows:
<pre>
"Content-Security-Policy-Report-Only:" 1#<a>policy-token</a>
</pre>
For example, server operators might wish to develop their
security policy iteratively. The operators can deploy a report-only
policy based on their best estimate of how their site behaves:
<div class="example">
<pre>
Content-Security-Policy-Report-Only: <a>script-src</a> 'self';
<a>report-uri</a> /csp-report-endpoint/
</pre>
</div>
If their site violates this policy the user agent will <a>send violation
reports</a> to the URL specified in the policy's <a>report-uri</a>
directive, but allow the violating resources to load regardless. Once a site
has confidence that the policy is appropriate, they can start enforcing the
policy using the <code><a>Content-Security-Policy</a></code> header field.
A server MUST NOT send more than one HTTP header field named
<code>Content-Security-Policy-Report-Only</code> with a given
<a>resource representation</a>.
A server MAY send different
<code>Content-Security-Policy-Report-Only</code> header field values
with different <a>representations</a> of the same resource or with different
resources.
Upon receiving an HTTP response containing at least one
<code>Content-Security-Policy-Report-Only</code> header field, the
user agent MUST <a>monitor</a> each of the policies
contained in each such header field.
Note: The <code><a>Content-Security-Policy-Report-Only</a></code>
header is <em>not</em> supported inside a <{meta}> element.
</section>
<section>
<h3 id="delivery-html-meta-element">
HTML <{meta}> Element
</h3>
The server MAY supply policy via one or more HTML <{meta}> elements
with <{meta/http-equiv}> attributes that are an <a>ASCII case-insensitive
match</a> for the string "<code>Content-Security-Policy</code>". For
example:
<pre class="example">
<meta http-equiv="Content-Security-Policy" content="<a>script-src</a> 'self'">
</pre>
Add the following entry to the <a>pragma directives</a> for the <{meta}>
element:
<dl>
<dt>
Content security policy
(<code>http-equiv="content-security-policy"</code>)
</dt>
<dd>
<ol>
<li>If the Document's <{head}> element is not an ancestor of the
<{meta}> element, abort these steps.</li>
<li>If the <{meta}> element lacks a <{meta/content}> attribute, abort
these steps.</li>
<li>Let <var>policy</var> be the value of the <{meta/content}>
attribute of the <{meta}> element.</li>
<li>Let <var>directive-set</var> be the result of
<a lt="parse the policy">parsing <var>policy</var></a>.</li>
<li>
Remove all occurrences of <code><a>report-uri</a></code>,
<code><a>frame-ancestors</a></code>, and <code><a>sandbox</a></code>
directives from <var>directive-set</var>.
Note: User agents are encouraged to issue a warning to developers
if one or more of these directives are included in a policy
delivered via <{meta}>.
</li>
<li>Enforce each of the <a>directives</a> in <var>directive-set</var>,
as <a href="#directives">defined for each directive type</a>.</li>
</ol>
</dd>
</dl>
Authors are <em>strongly encouraged</em> to place <{meta}> elements as early
in the document as possible, because policies in <{meta}> elements are not
applied to content which precedes them. In particular, note that resources
fetched or prefetched using the <code>Link</code> HTTP response header
field, and resources fetched or prefetched using <{link}> and <{script}>
elements which precede a <{meta}>-delivered policy will not be blocked.
Note: A <a>policy</a> specified via a <{meta}> element will be enforced
along with any other policies active for the protected resource, regardless
of where they're specified. The general impact of enforcing multiple
policies is described in [[#enforcing-multiple-policies]].
Note: Modifications to the <{meta/content}> attribute of a <{meta}> element
after the element has been parsed will be ignored.
Note: The <code><a>Content-Security-Policy-Report-Only</a></code>
header is <em>not</em> supported inside a <{meta}> element.
</section>
<section>
<h3 id="enforcing-multiple-policies">Enforcing multiple policies</h3>
<em>This section is not normative.</em>
The above sections note that when multiple policies are present,
each must be enforced or reported, according to its type. An example
will help clarify how that ought to work in practice. The behavior of
an <code>XMLHttpRequest</code> might seem unclear given a site
that, for whatever reason, delivered the following HTTP headers:
<pre class="example">
Content-Security-Policy: <a>default-src</a> 'self' http://example.com http://example.net;
<a>connect-src</a> 'none';
Content-Security-Policy: <a>connect-src</a> http://example.com/;
<a>script-src</a> http://example.com/
</pre>
Is a connection to <code>example.com</code> allowed or not? The
short answer is that the connection is not allowed. Enforcing both
policies means that a potential connection would have to pass through
both unscathed. Even though the second policy would allow this
connection, the first policy contains <code><a>connect-src</a>
'none'</code>, so its enforcement blocks the connection. The impact is
that adding additional policies to the list of policies to enforce can
only further restrict the capabilities of the protected resource.
To demonstrate that further, consider a script tag on this page.
The first policy would lock scripts down to <code>'self'</code>,
<code>http://example.com</code> and <code>http://example.net</code>
via the <code><a>default-src</a></code> directive. The second, however,
would only allow script from <code>http://example.com/</code>. Script
will only load if it meets both policy's criteria: in this case, the only
origin that can match is <code>http://example.com</code>, as both
policies allow it.
</section>
<section>
<h3 id="which-policy-applies">Policy applicability</h3>
<em>This section is not normative.</em>
Policies are associated with an <a>protected resource</a>, and
<a lt="enforce">enforced</a> or <a>monitored</a> for that resource.
If a resource does not create a new execution context (for example, when
including a script, image, or stylesheet into a document), then any policies
delivered with that resource are discarded without effect. Its execution is
subject to the policy or policies of the including context. The following
table outlines examples of these relationships:
<style>
table {
text-align: left;
margin: 20px;
width: 100%;
border-collapse: collapse;
}
tbody tr:nth-child(odd) {
background-color: #EEE;
}
th {
border-bottom: 1px solid #999;
padding: 0.5em;
}
td:first-child {
width: 30%;
padding-right: 1em;
}
td {
vertical-align: top;
padding: 0.5em;
}
tbody th {
border: 0;
background-color: #FFF;
}
tr.section {
border-top: 1px solid #999;
vertical-align: top;
}
</style>
<table>
<thead>
<tr>
<th colspan="2">Resource Type</th>
<th>What <a>policy</a> applies?</th>
</tr>
</thead>
<tbody>
<tr class="section">
<th rowspan="2">Top-level Contexts</th>
<td>HTML as a new, top-level browsing context</td>
<td>The policy delivered with the resource applies.</td>
</tr>
<tr>
<td>SVG, as a top-level document</td>
<td>The policy delivered with the resource applies.</td>
</tr>
<tr class="section">
<th rowspan="3">Embedded Contexts</th>
<td>
Any resource included via <{iframe}>, <{object}>, or <{embed}>
</td>
<td>
Unless the embedded resource is a globally unique identifier (or a
srcdoc iframe), the embedded resource is controlled by the policy
delivered with the resource. If the embedded resource is a globally
unique identifier or srcdoc iframe, it inherits the policy of the
context creating it. (The frame-src and
child-src directives of the embedding context only control
what resources are eligible for embedding in that context, not the
behavior of the resource once embedded.)
</td>
</tr>
<tr>
<td>SVG, as an embedded document</td>
<td>
Unless the resource is a globally unique identifier,
it is controlled by the policy
delivered with the resource. If a globally
unique identifier, it inherits the policy of the
context creating it.
</td>
</tr>
<tr>
<td>
JavaScript, as a Worker, Shared Worker, or Service Worker
</td>
<td>
Unless the resource is a globally unique identifier,
it is controlled by the
policy delivered with the resource. If a globally
unique identifier, it inherits the policy of the
context creating it.
</td>
</tr>
<tr class="section">
<th rowspan="7">Subresources</th>
<td>SVG, inlined via <{svg}></td>
<td>The policy of the including context applies.</td>
</tr>
<tr>
<td>SVG, as a resource document</td>
<td>The policy of the including context applies.</td>
</tr>
<tr>
<td>HTML via XMLHttpRequest</td>
<td>The policy of the context that performed the fetch applies.</td>
</tr>
<tr>
<td>Image via <{img}> element</td>
<td>The policy of the including context applies.</td>
</tr>
<tr>
<td>JavaScript via a <{script}> element</td>
<td>The policy of the including context applies.</td>
</tr>
<tr>
<td>SVG, via <{img}></td>
<td>No policy applies; this should be just as safe as JPG</td>
</tr>
<tr>
<td>SVG, as a WebFont</td>
<td>No policy applies; this should be just as safe as WOFF</td>
</tr>
</tbody>
</table>
</section>
</section>
<!--
██████ ██ ██ ██ ██ ████████ ███ ██ ██
██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██
██ ████ ████ ██ ██ ██ ██ ██ ██
██████ ██ ██ ██ ██ ██ ██ ██ ███
██ ██ ██ ████ ██ █████████ ██ ██
██ ██ ██ ██ ███ ██ ██ ██ ██ ██
██████ ██ ██ ██ ██ ██ ██ ██ ██
-->
<section>
<h2 id="syntax-and-algorithms">Syntax and Algorithms</h2>
<section>
<h3 id="policy-syntax">Policy Syntax</h3>
A Content Security Policy consists of a U+003B SEMICOLON
(<code>;</code>) delimited list of directives. Each <a>directive</a>
consists of a <a>directive name</a> and (optionally) a
<a>directive value</a>, defined by the following ABNF:
<pre>
<dfn>policy-token</dfn> = [ <a>directive-token</a> *( ";" [ <a>directive-token</a> ] ) ]
<dfn>directive-token</dfn> = *WSP [ <a>directive-name</a> [ WSP <a>directive-value</a> ] ]
<dfn>directive-name</dfn> = 1*( ALPHA / DIGIT / "-" )
<dfn>directive-value</dfn> = *( WSP / <VCHAR except ";" and ","> )
</pre>
<section>
<h4 id="policy-parsing">Parsing Policies</h4>
To <dfn>parse the policy</dfn> <var>policy</var>, the user agent MUST
use an algorithm equivalent to the following:
<ol>
<li>Let the <var>set of directives</var> be the empty set.</li>
<li>For each non-empty token returned by
<a lt="strictly split a string" spec="HTML5">strictly splitting</a>
the string <var>policy</var> on the character U+003B SEMICOLON
(<code>;</code>):
<ol>
<li><a spec="HTML5">Skip whitespace</a>.</li>
<li><a spec="HTML5">Collect a sequence of characters</a> that are
not <a spec="HTML5">space characters</a>. The collected characters
are the <var>directive name</var>.</li>
<li>If there are characters remaining in <var>token</var>,
skip ahead exactly one character (which must be a
<a spec="HTML5">space character</a>).</li>
<li>The remaining characters in <var>token</var> (if any) are
the <var>directive value</var>.</li>
<li>If the <var>set of directives</var> already contains a
directive whose name is a case insensitive match for
<var>directive name</var>, ignore this instance of the directive
and continue to the next token.</li>
<li>Add a <var>directive</var> to the <var>set of
directives</var> with name <var>directive name</var> and value
<var>directive value</var>.</li>
</ol>
</li>
<li>Return the <var>set of directives</var>.
</ol>
</section>
</section>
<section>
<h3 id="source-list-syntax">Source List Syntax</h3>
Many CSP directives use a value consisting of a <dfn>source
list</dfn>, defined in the ABNF grammar below.
Each <dfn>source expression</dfn> in the source list represents a
location from which content of the specified type can be retrieved.
For example, the source expression <code>'none'</code> represents
the empty set of URLs, and the source expression
<code>'unsafe-inline'</code> represents content supplied inline in the
resource itself.
<pre>
<dfn>source-list</dfn> = *WSP [ <a>source-expression</a> *( 1*WSP <a>source-expression</a> ) *WSP ]
/ *WSP "'none'" *WSP
<dfn>source-expression</dfn> = <a>scheme-source</a> / <a>host-source</a> / <a>keyword-source</a> / <a>nonce-source</a> / <a>hash-source</a>
<dfn>scheme-source</dfn> = <a>scheme-part</a> ":"
<dfn>host-source</dfn> = [ <a>scheme-part</a> "://" ] <a>host-part</a> [ <a>port-part</a> ] [ <a>path-part</a> ]
<dfn>keyword-source</dfn> = "'self'" / "'unsafe-inline'" / "'unsafe-eval'"
<dfn>base64-value</dfn> = 1*( ALPHA / DIGIT / "+" / "/" )*2( "=" )
<dfn>nonce-value</dfn> = <a>base64-value</a>
<dfn>hash-value</dfn> = <a>base64-value</a>
<dfn>nonce-source</dfn> = "'nonce-" <a>nonce-value</a> "'"
<dfn>hash-algo</dfn> = "sha256" / "sha384" / "sha512"
<dfn>hash-source</dfn> = "'" <a>hash-algo</a> "-" <a>hash-value</a> "'"
<dfn>scheme-part</dfn> = <scheme production from <a href="https://tools.ietf.org/html/rfc3986#section-3.1">RFC 3986, section 3.1</a>>
<dfn>host-part</dfn> = "*" / [ "*." ] 1*<a>host-char</a> *( "." 1*<a>host-char</a> )
<dfn>host-char</dfn> = ALPHA / DIGIT / "-"
<dfn>path-part</dfn> = <path production from <a href="https://tools.ietf.org/html/rfc3986#section-3.3">RFC 3986, section 3.3</a>>
<dfn>port-part</dfn> = ":" ( 1*DIGIT / "*" )
</pre>
If the policy contains a <code><a>nonce-source</a></code> expression, the
server MUST generate a fresh value for the <code><a>nonce-value</a></code>
directive at random and independently each time it transmits a policy.
The generated value SHOULD be at least 128 bits long (before encoding),
and generated via a cryptographically secure random number generator.
This requirement ensures that the <code><a>nonce-value</a></code> is
difficult for an attacker to predict.
Note: Using a nonce to whitelist inline script or style is less secure than
not using a nonce, as nonces override the restrictions in the directive in
which they are present. An attacker who can gain access to the nonce can
execute whatever script they like, whenever they like. That said, nonces
provide a substantial improvement over <code>'unsafe-inline'</code> when
layering a content security policy on top of old code. When considering
<code>'unsafe-inline'</code>, authors are encouraged to consider nonces (or
hashes) instead.
The <code><a>host-char</a></code> production intentionally contains only
ASCII characters; internationalized domain names cannot be entered
directly into a policy string, but instead MUST be Punycode-encoded
[[!RFC3492]]. For example, the domain <code>üüüüüü.de</code> would be
encoded as <code>xn--tdaaaaaa.de</code>.
NOTE: Though IP addresses do match the grammar above, only
<code>127.0.0.1</code> will actually match a URL when used in a source
expression (see [[#match-source-expression]] for details). The security
properties of IP addresses are suspect, and authors ought to prefer
hostnames to IP addresses whenever possible.
<section>
<h4 id="source-list-parsing">Parsing Source Lists</h4>
To <dfn id="parse-a-source-list">parse a source list</dfn>
<var>source list</var>, the user agent MUST use an algorithm
equivalent to the following:
<ol>
<li><a spec="HTML5">Strip leading and trailing whitespace</a> from
<var>source list</var>.</li>
<li>If <var>source list</var> is an <a>ASCII case-insensitive match</a>
for the string <code>'none'</code> (including the quotation
marks), return the empty set.</li>
<li>Let <var>set of source expressions</var> be the empty
set.</li>
<li>For each token returned by
<a lt="split a string on spaces" spec="HTML5">splitting <var>source
list</var> on spaces</a>, if the token matches the grammar for
<code><a>source-expression</a></code>, add the token to the <var>set
of source expressions</var>.</li>
<li>Return the <var>set of source expressions</var>.</li>
</ol>
Note: Characters like U+003B SEMICOLON (<code>;</code>) and
U+002C COMMA (<code>,</code>) cannot appear in source expressions
directly: if you'd like to include these characters in a source
expression, they must be <a lt="percent encode" spec="HTML5">percent
encoded</a> as <code>%3B</code> and <code>%2C</code> respectively.
</section>
<section>
<h4 id="match-source-expression">Matching Source Expressions</h4>
A URL <var>url</var> is said to <dfn>match a source expression</dfn> for
a <var>protected resource</var> if the following algorithm returns
<em>does match</em>:
<ol>
<li>
Let <var>url</var> be the result of processing the URL through the
<a>URL parser</a>.
</li>
<li>
If the source expression consists of a single U+002A ASTERISK
character (<code>*</code>), and <var>url</var>'s <a>scheme</a> is not
one of <code>blob</code>, <code>data</code>, <code>filesystem</code>,
then return <em>does match</em>.
</li>
<li>
If the source expression matches the grammar for
<code><a>scheme-source</a></code>:
<ol>
<li>
If <var>url</var>'s <a>scheme</a> is an <a>ASCII case-insensitive
match</a> for the source expression's
<code><a>scheme-part</a></code>, return <em>does match</em>.
</li>
<li>
Otherwise, return <em>does not match</em>.
</li>
</ol>
</li>
<li>
If the source expression matches the grammar for
<code><a>host-source</a></code>:
<ol>
<li>
If <var>url</var>'s <a>host</a> is <code>null</code>,
return <em>does not match</em>.
</li>
<li>
Let <var>url-scheme</var>, <var>url-host</var>, and
<var>url-port</var> be the <a>scheme</a>, <a>host</a>, and
<a>port</a> of <var>url</var>'s origin, respectively.
Note: If <var>url</var> doesn't specify a port, then its origin's
port will be the <a>default port</a> for <var>url</var>'s
<a>scheme</a>.
</li>
<li>
Let <var>url-path-list</var> be the <a>path</a> of <var>url</var>.
</li>
<li>
If the source expression has a <code><a>scheme-part</a></code>
that is not a case insensitive match for <var>url-scheme</var>,
then return <em>does not match</em>.
</li>
<li>
If the source expression does <strong>not</strong> have a
scheme, return <em>does not match</em> if any of the following
are true:
<ol>
<li>
The scheme of the protected resource's URL is a case
insensitive match for <code>HTTP</code>, and
<var>url-scheme</var> is <strong>not</strong> a case
insensitive match for either <code>HTTP</code> or
<code>HTTPS</code>.
</li>
<li>
The scheme of the protected resource's URL is
<strong>not</strong> a case insensitive match for
<code>HTTP</code>, and <var>url-scheme</var> is
<strong>not</strong> a case insensitive match
for the scheme of the protected resource's URL.
</li>
</ol>
</li>
<li>
If the first character of the source expression's
<code><a>host-part</a></code> is an U+002A ASTERISK character
(<code>*</code>) and the remaining characters, including the
leading U+002E FULL STOP character (<code>.</code>), are not a
case insensitive match for the rightmost characters of
<var>url-host</var>, then return <em>does not match</em>.
</li>
<li>
If the first character of the source expression's
<code><a>host-part</a></code> is <em>not</em> an U+002A ASTERISK
character (<code>*</code>) and <var>url-host</var> is not a
case insensitive match for the source expression's
<code><a>host-part</a></code>, then return <em>does not
match</em>.
</li>
<li>
If the source expression's <code><a>host-part</a></code> matches
the <code><a>IPv4address</a></code> production from [[!RFC3986]],
and is not <code>127.0.0.1</code>, or is an <a>IPv6 address</a>,
return <em>does not match</em>.
Note: A future version of this specification may allow literal
IPv6 and IPv4 addresses, depending on usage and demand. Given the
weak security properties of IP addresses in relation to named
hosts, however, authors are encouraged to prefer the latter
whenever possible.
</li>
<li>
If the source expression does <strong>not</strong> contain
a <code>port-part</code> and <var>url-port</var> is not the
<a>default port</a> for <var>url-scheme</var>, then return
<em>does not match</em>.
</li>
<li>
If the source expression does contain a <code>port-part</code>,
then return <em>does not match</em> if both of the following
are true:
<ol>
<li>
The <code><a>port-part</a></code> does <strong>not</strong>
contain an U+002A ASTERISK character. (<code>*</code>)
</li>
<li>
The <code><a>port-part</a></code> does <strong>not</strong>
represent the same number as <var>url-port</var>.
</li>
</ol>
</li>
<li>
If the source expression contains a non-empty
<code><a>path-part</a></code>, and the URL is <em>not</em> the
result of a redirect, then:
<ol>
<li>
Let <var>exact-match</var> be <code>true</code> if the final
character of <var>path-part</var> is not the U+002F SOLIDUS
character (<code>/</code>), and <code>false</code> otherwise.
</li>
<li>
Let <var>source-expression-path-list</var> be the result of
splitting <var>path-part</var> on the U+002F SOLIDUS character
(<code>/</code>).
</li>
<li>
If <var>source-expression-path-list</var>'s length is greater
than <var>url-path-list</var>'s length, return <em>does not
match</em>.
</li>
<li>
For each <var>entry</var> in
<var>source-expression-path-list</var>:
<ol>
<li>
<a>Percent decode</a> <var>entry</var>.
</li>
<li>
<a>Percent decode</a> the first item in
<var>url-path-list</var>.
</li>
<li>
If <var>entry</var> is not an <a>ASCII case-insensitive
match</a> for the first item in <var>url-path-list</var>,
return <em>does not match</em>.
</li>
<li>
Pop the first item in <var>url-path-list</var> off the
list.
</li>
</ol>
</li>
<li>
If <var>exact-match</var> is <code>true</code>, and
<var>url-path-list</var> is not empty, return <em>does not
match</em>.
</li>
</ol>
</li>
<li>
Otherwise, return <em>does match</em>.
</li>
</ol>
</li>
<li>
If the source expression is a case insensitive match for
<code>'self'</code> (including the quotation marks), then:
<ol>
<li>
Return <em>does match</em> if <a lt="origin of a url">the
origin of <var>url</var></a> matches
<a lt="origin of a url">the origin of <var>protected
resource</var>'s URL</a>.
Note: This includes IP addresses. That is, a document at
<code>https://111.111.111.111/</code> with a <a>policy</a> of
<code>img-src 'self'</code> can load the image
<code>https://111.111.111.111/image.png</code>, as the origins
match.
</li>
</ol>
</li>
<li>
Otherwise, return <em>does not match</em>.
</li>
</ol>
Note: This algorithm treats the URLs <code>https://example.com/</code>
and <code>https://example.com./</code> as <em>non-matching</em>. This
is consistent with browser behavior which treats documents served from
these URLs as existing in distinct origins.
A URL <var>url</var> is said to <dfn>match a source list</dfn> for
<var>protected resource</var> if at least one source expression in the set
of source expressions obtained by <a lt="parse a source list">parsing the
source list</a> <a lt="match a source expression">matches <var>url</var>
for <var>protected resource</var></a>.
Note: No URLs match an empty set of source expressions, such as the set
obtained by parsing the source list <code>'none'</code>.
<section class="informative">
<h5 id="source-list-guid-matching">
Security Considerations for GUID URL schemes
</h5>
<em>This section is not normative.</em>
As defined above, special URL schemes that refer to specific pieces of
unique content, such as "data:", "blob:" and "filesystem:" are
excluded from matching a policy of <code>*</code> and must be
explicitly listed. Policy authors should note that the content of
such URLs is often derived from a response body or execution in a
Document context, which may be unsafe. Especially for the
<code><a>default-src</a></code> and <code><a>script-src</a></code>
directives, policy authors should be aware that allowing "data:" URLs
is equivalent to <code>unsafe-inline</code> and allowing "blob:" or
"filesystem:" URLs is equivalent to <code>unsafe-eval</code>.
</section>
<section class="informative">
<h5 id="source-list-path-patching">Path Matching</h5>
<em>This section is not normative.</em>
The rules for matching source expressions that contain paths
are simpler than they look: paths that end with the <code>'/'</code>
character match all files in a directory and its subdirectories. Paths
that do not end with the <code>'/'</code> character match only one
specific file. A few examples should make this clear:
<ol>
<li>The source expression <code>example.com</code> has no path,
and therefore matches any file served from that host.</li>
<li>The source expression <code>example.com/scripts/</code>
matches any file in the <code>scripts</code> directory of
<code>example.com</code>, and any of its subdirectories. For
example, both <code>https://example.com/scripts/file.js</code>
and <code>https://example.com/scripts/js/file.js</code> would
match.</li>
<li>The source expression
<code>example.com/scripts/file.js</code> matches only the file
named <code>file.js</code> in the <code>scripts</code> directory
of <code>example.com</code>.</li>
<li>Likewise, the source expression <code>example.com/js</code>
matches only the file named <code>js</code>. In particular, note
that it would not match files inside a directory named
<code>js</code>. Files like <code>example.com/js/file.js</code>
would be matched only if the source expression ended with a
trailing "/", as in <code>example.com/js/</code>.</li>
</ol>
Note: Query strings have no impact on matching: the source
expression <code>example.com/file</code> matches each of
<code>https://example.com/file</code>,
<code>https://example.com/file?key=value</code>,
<code>https://example.com/file?key=notvalue</code>, and
<code>https://example.com/file?notkey=notvalue</code>.
</section>
<section class="informative">
<h5 id="source-list-paths-and-redirects">Paths and Redirects</h5>
To avoid leaking path information cross-origin (as discussed
in Egor Homakov's
<a href="http://homakov.blogspot.de/2014/01/using-content-security-policy-for-evil.html">Using Content-Security-Policy for Evil</a>),
the matching algorithm ignores the path component of a source
expression if the resource being loaded is the result of a
redirect. For example, given a page with an active policy of
<code><a>img-src</a> example.com not-example.com/path</code>:
<ul>
<li>Directly loading <code>https://not-example.com/not-path</code>
would fail, as it doesn't match the policy.</li>
<li>Directly loading <code>https://example.com/redirector</code>
would pass, as it matches <code>example.com</code>.</li>
<li>Assuming that <code>https://example.com/redirector</code>
delivered a redirect response pointing to <code>https://not-example.com/not-path</code>,
the load would succeed, as the initial URL matches <code>example.com</code>,
and the redirect target matches <code>not-example.com/path</code>
if we ignore its path component.</li>
</ul>
This restriction reduces the granularity of a document's
policy when redirects are in play, a necessary compromise to
avoid brute-forced information leaks of this type.
The relatively long thread
<a href="http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0036.html">"Remove paths from CSP?"</a>
from public-webappsec@w3.org has more detailed discussion around
alternate proposals.
</section>
</section>
<section>
<h4 id="script-src-the-nonce-attribute">
The <code>nonce</code> attribute
</h4>
Nonce sources require a new <code>nonce</code> attribute to be added to
both <{script}> and <{style}> elements.
<pre class="idl">
partial interface HTMLScriptElement {
attribute DOMString nonce;
};
</pre>
<dl dfn-for="HTMLScriptElement">
<dt><dfn attribute>nonce</dfn></dt>
<dd>This attribute <a spec="HTML5">reflects</a> the value of the
element's <code><dfn element-attr for="script">nonce</a></code>
content attribute.</dd>
</dl>
<pre class="idl">
partial interface HTMLStyleElement {
attribute DOMString nonce;
};
</pre>
<dl dfn-for="HTMLStyleElement">
<dt><dfn attribute>nonce</dfn></dt>
<dd>This attribute <a spec="HTML5">reflects</a> the value of the
element's <code><dfn element-attr for="style">nonce</a></code>
content attribute.</dd>
</dl>
</section>
<section>
<h4 id="source-list-valid-nonces">Valid Nonces</h4>
An element has a <dfn>valid nonce</dfn> for a <var>set of source
expressions</var> if the value of the element's <{script/nonce}> attribute
after <a lt="strip leading and trailing whitespace">stripping leading
and trailing whitespace</a> is a case-sensitive match for the
<code><a>nonce-value</a></code> component of at least one
<code><a>nonce-source</a></code> expression in <var>set of source
expressions</var>.
</section>
<section>
<h4 id="source-list-valid-hashes">Valid Hashes</h4>
An <dfn>element's content</dfn> is <a spec="HTML5">the script block's
source</a> for <{script}> elements, or the value of the element's
{{Node/textContent}} IDL attribute for non-<{script}> elements such as
<{style}>.
The <dfn>digest of <var>element</var>'s content</dfn> for is the result
of applying an <var>hashing algorithm</var> to the <a>element's content</a>.
To determine whether <var>element</var> has a <dfn>valid hash</dfn> for
a <var>set of source expressions</var>, execute the following steps:
<ol>
<li>Let <var>hashes</var> be a list of all
<code><a>hash-source</a></code> expressions in <var>set of source
expressions</var>.</li>
<li>For each <var>hash</var> in <var>hashes</var>:
<ol>
<li>Let <var>hashing algorithm</var> be:
<ul>
<li><a>SHA-256</a> if the <code><a>hash-algo</a></code>
component of <var>hash</var> is an <a>ASCII case-insensitive
match</a> for the string "sha256".</li>
<li><a>SHA-384</a> if the <code><a>hash-algo</a></code>
component of <var>hash</var> is an <a>ASCII case-insensitive
match</a> for the string "sha384".</li>
<li><a>SHA-512</a> if the <code><a>hash-algo</a></code>
component of <var>hash</var> is an <a>ASCII case-insensitive
match</a> for the string "sha512".</li>
</ul>
</li>
<li>Let <var>expected</var> be the <code><a>hash-value</a></code>
component of <var>hash</var>.</li>
<li>Let <var>actual</var> be the
<a href="https://tools.ietf.org/html/rfc4648#section-4">base64
encoding</a> of the binary <a>digest of <var>element</var>'s
content</a> using the <var>hashing algorithm</var>.</li>
<li>If <var>actual</var> is a case-sensitive match for
<var>expected</var>, return <strong>true</strong> and abort these
steps.</li>
</ol>
</li>
<li>Return <strong>false</strong>.</li>
</ol>
Note: If an element has an invalid hash, it would be helpful
if the user agent reported the failure to the author by adding
a warning message containing the <var>actual</var> hash value.
</section>
</section>
<section>
<h3 id="media-type-list-syntax">Media Type List Syntax</h3>
The <code><a>plugin-types</a></code> directive uses a value consisting
of a <dfn>media type list</dfn>.
Each <dfn>media type</dfn> in the media type list represents a specific
type of resource that can be retrieved and used to instantiate a
<a>plugin</a> in the protected resource.
<pre>
<dfn>media-type-list</dfn> = <a>media-type</a> *( 1*WSP <a>media-type</a> )
<dfn>media-type</dfn> = <type from RFC 2045> "/" <subtype from RFC 2045>
</pre>
<section>
<h4 id="media-type-list-parsing">Parsing</h4>
To <dfn>parse a media type list</dfn> <var>media type list</var>, the
user agent MUST use an algorithm equivalent to the following:
<ol>
<li>Let the <var>set of media types</var> be the empty set.</li>
<li>For each token returned by
<a lt="split a string on spaces" spec="HTML5">splitting
<var>media type list</var> on spaces</a>, if the token matches the
grammar for <code><a>media-type</a></code>, add the token to the
<var>set of media types</var>. Otherwise ignore the token.</li>
<li>Return the <var>set of media types</var>.</li>
</ol>
</section>
<section>
<h4 id="media-type-list-matching">Matching</h4>
A media type <dfn lt="match a media type list">matches a media type
list</dfn> if, and only if, the media type is an <a>ASCII
case-insensitive match</a> for at least one token in the set of media
types obtained by <a lt="parse a media type list">parsing the media
type list</a>.
</section>
</section>
<section>
<h3 id="violation-reports">Reporting</h3>
To <dfn lt="strip uri for reporting|stripped for reporting">strip
<var>uri</var> for reporting</dfn>, the user agent MUST use an
algorithm equivalent to the following:
<ol>
<li>If the <a>origin</a> of <var>uri</var> is a <a>globally unique
identifier</a> (for example, <var>uri</var> has a scheme of
<code>data</code>, <code>blob</code>, or <code>filesystem</code>), then
abort these steps, and return the ASCII serialization of
<var>uri</var>'s scheme.</li>
<li>If the <a>origin</a> of <var>uri</var> is not the same as the
<a>origin</a> of the protected resource, then abort these steps, and
return the
<a lt="ascii serialization of an origin" spec="HTML5">ASCII
serialization of <var>uri</var>'s origin</a>.</li>
<li>Return <var>uri</var>, with any <a spec="HTML5">fragment</a>
component removed.</li>
</ol>
To <dfn lt="generate a violation report object|generating a violation report object">generate a violation report object</dfn>,
the user agent MUST use an algorithm equivalent to the following:
<ol>
<li>Prepare a JSON object <var>violation</var> with the
following keys and values:
<dl>
<dt id="violation-report-blocked-uri">blocked-uri</dt>
<dd>The originally requested URL of the resource that was
prevented from loading, <a>stripped for reporting</a>,
or the empty string if the resource has no URL (inline script and
inline style, for example).</dd>
<dt id="violation-report-document-uri">document-uri</dt>
<dd>The <a lt="the document's address" spec="HTML5">address</a>
of the protected resource, <a>stripped for reporting</a>.</dd>
<dt id="violation-report-effective-directive">effective-directive</dt>
<dd>The name of the policy directive that was violated. This will
contain the <a>directive</a> whose enforcement triggered the
violation (e.g. "<code><a>script-src</a></code>") even if that
directive does not explicitly appear in the policy, but is
implicitly activated via the <code><a>default-src</a></code>
directive.</dd>
<dt id="violation-report-original-policy">original-policy</dt>
<dd>The original <a>policy</a>, as received by the user agent.</dd>
<dt id="violation-report-referrer">referrer</dt>
<dd>The <a attribute for="Document">referrer</a> attribute of the protected
resource, or the empty string if the protected resource has no
referrer.</dd>
<dt id="violation-report-status-code">status-code</dt>
<dd>The <code>status-code</code> of the HTTP response that
contained the protected resource, if the protected resource was
obtained over HTTP. Otherwise, the number 0.</dd>
<dt id="violation-report-violated-directive">violated-directive</dt>
<dd>The policy directive that was violated, as it appears in the
policy. This will contain the <code><a>default-src</a></code> directive
in the case of violations caused by falling back to the
<a>default sources</a> when enforcing
a directive.</dd>
</dl>
</li>
<li>If a specific line or a specific file can be identified as the
cause of the violation (for example, script execution that violates
the <code><a>script-src</a></code> directive), the user agent MAY add the
following keys and values to <var>violation</var>:
<dl>
<dt id="violation-report-source-file"><dfn>source-file</dfn></dt>
<dd>The URL of the resource where the violation occurred,
<a>stripped for reporting</a>.</dd>
<dt id="violation-report-line-number">line-number</dt>
<dd>The line number in <code><a>source-file</a></code> on which
the violation occurred.</dd>
<dt id="violation-report-column-number">column-number</dt>
<dd>The column number in <code><a>source-file</a></code> on which
the violation occurred.</dd>
</dl>
</li>
<li>Return <var>violation</var>.</li>
</ol>
Note: <code>blocked-uri</code> will not contain the final location of a
resource that was blocked after one or more redirects. It instead will
contain only the location that the protected resource requested, before
any redirects were followed.
To <dfn>send violation reports</dfn>, the user agent MUST use an
algorithm equivalent to the following:
<ol>
<li>Prepare a <a>JSON object</a> <var>report object</var> with a single
key, <code>csp-report</code>, whose value is the result of <a>generating
a violation report object</a>.</li>
<li>Let <var>report body</var> be the <a>JSON stringification</a> of
<var>report object</var>.</li>
<li>For each <var>report URL</var> in the <a>set of report URLs</a>:
<ol>
<li>If the user agent has already sent a violation report for
the protected resource to <var>report URL</var>, and that report
contained an entity body that exactly matches
<var>report body</var>, the user agent MAY abort these
steps and continue to the next <var>report URL</var>.</li>
<li><a spec="HTML5">Queue a task</a> to <a>fetch</a>
<var>report URL</var> from the origin of the protected resource,
with the synchronous flag <em>not</em> set, using HTTP method
<code>POST</code>, with a <code>Content-Type</code> header field
of <code>application/csp-report</code>, and an entity body
consisting of <var>report body</var>. If the origin of
<var>report URL</var> is <strong>not</strong> the same as the
origin of the protected resource, the block cookies flag MUST also
be set. The user agent MUST NOT follow redirects when fetching this
resource. (Note: The user agent ignores the fetched resource.)
The <a spec="HTML5">task source</a> for these
<a spec="HTML5">tasks</a> is the <dfn>Content Security Policy task
source</dfn>.</li>
</ol>
</li>
</ol>
To <dfn>report a violation</dfn>, the user agent MUST:
<ol>
<li><a>Fire a violation event</a> at the protected resource's
<code><a interface spec="HTML5">Document</a></code>.</li>
<li>If the <a>set of report URLs</a> is non-empty, <a>send violation
reports</a> to each.</li>
</ol>
Note: This section of the specification should not be interpreted
as limiting user agents' ability to apply restrictions to violation
reports in order to limit data leakage above and beyond what these
algorithms specify. For example, a user agent might offer users the
option of disabling reporting entirely.
</section>
</section>
<!--
████████ ████████ ███████ ██████ ████████ ██████ ██████ ████ ██ ██ ██████ ██ ██ ███████ ████████ ████████ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ███ ███ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ████ ██ ██ ████ ████ ██ ██ ██ ██ ██ ██
████████ ████████ ██ ██ ██ ██████ ██████ ██████ ██ ██ ██ ██ ██ ████ ██ ███ ██ ██ ██ ██ ██ ██████ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ███████ ██████ ████████ ██████ ██████ ████ ██ ██ ██████ ██ ██ ███████ ████████ ████████ ████████
-->
<section>
<h2 id="processing-model">Processing Model</h2>
To <dfn>enforce</dfn> a policy, the user agent MUST <a>parse the policy</a>
and enforce each of the directives contained in the policy, where the
specific requirements for enforcing each directive are defined separately
for each directive (See <a section href="#directives"></a>, below).
Generally speaking, enforcing a directive prevents the protected
resource from performing certain actions, such as loading scripts from
URLs other than those indicated in a source list. These restrictions
make it more difficult for an attacker to abuse an injection
vulnerability in the resource because the attacker will be unable to
usurp the resource's privileges that have been restricted in this
way.
Note: User agents may allow users to modify or bypass policy enforcement
through user preferences, bookmarklets, third-party additions to the user
agent, and other such mechanisms.
To <dfn>monitor</dfn> a policy, the user agent MUST <a>parse the policy</a>
and monitor each of the directives contained in the policy.
Monitoring a directive does not prevent the protected resource from
undertaking any actions. Instead, any actions that would have been
prevented by the directives are allowed, but a violation report is
<a lt="report a violation">generated and reported</a> to the
developer of the web application. Monitoring a policy is useful for
testing whether enforcing the policy will cause the web application to
malfunction.
A server MAY cause user agents to monitor one policy while enforcing
another policy by returning both <code><a>Content-Security-Policy</a></code>
and <code><a>Content-Security-Policy-Report-Only</a></code> header fields.
For example, if a server operator may wish to <a>enforce</a> one policy but
experiment with a stricter policy, she can monitor the stricter policy while
enforcing the original policy. Once the server operator is satisfied that
the stricter policy does not break the web application, the server operator
can start enforcing the stricter policy.
If the user agent monitors or enforces a policy that does not contain any
directives, the user agent SHOULD report a warning message in the
developer console.
If the user agent <a>monitors</a> or <a>enforces</a> a policy that contains
an unrecognized directive, the user agent SHOULD report a warning message
in the developer console indicating the name of the unrecognized directive.
<section>
<h3 id="processing-model-workers">Workers</h3>
Whenever a user agent <a>runs a worker</a>:
<ul>
<li>If the worker's script's origin is a <a>globally unique identifier</a>
(for example, the worker's script's URL has a scheme of
<code>data</code>, <code>blob</code>, or <code>filesystem</code>), then:
<ul>
<li>If the user agent is enforcing a CSP policy for the <var>owner
document</var> or <var>parent worker</var>, the user agent MUST enforce
the CSP policy for the worker.</li>
<li>If the user agent is monitoring a CSP policy for the <var>owner
document</var> or <var>parent worker</var>, the user agent MUST monitor
the CSP policy for the worker.</li>
</ul></li>
<li>Otherwise:
<ul>
<li>If the worker's script is delivered with a
<code>Content-Security-Policy</code> HTTP header containing the
value <var>policy</var>, the user agent MUST <a>enforce</a>
<var>policy</var> for the worker.</li>
<li>If the worker's script is delivered with a
<code>Content-Security-Policy-Report-Only</code> HTTP header
containing the value <var>policy</var>, the user agent MUST
<a>monitor</a> <var>policy</var> for the worker.</li>
</ul>
</li>
</ul>
</section>
<section>
<h3 id="processing-model-iframe-srcdoc"><code>srcdoc</code> iframes</h3>
Whenever a user agent creates <a spec="HTML5">an <code>iframe</code>
<code>srcdoc</code> document</a> in a browsing context nested in the
protected resource, if the user agent is <a>enforcing</a> any <a>policies</a>
for the protected resource, the user agent MUST <a>enforce</a> those
<a>policies</a> on the <{iframe}> <code>srcdoc</code> document as well.
Whenever a user agent creates <a spec="HTML5">an <code>iframe</code>
<code>srcdoc</code> document</a> in a browsing context nested in the
protected resource, if the user agent is monitoring any policies for the
protected resource, the user agent MUST <a>monitor</a> those policies on
the <{iframe}> <code>srcdoc</code> document as well.
</section>
</section>
<!--
██████ ██████ ████████ ████ ████████ ████████ ████ ██ ██ ████████ ████████ ████████ ████████ ███ ██████ ████████ ██████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██████ ██ ████████ ██ ████████ ██ ██ ██ ██ ██ ██ ██████ ████████ ██████ ██ ██ ██ ██████ ██████
██ ██ ██ ██ ██ ██ ██ ██ ██ ████ ██ ██ ██ ██ ██ █████████ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██████ ██████ ██ ██ ████ ██ ██ ████ ██ ██ ██ ████████ ██ ██ ██ ██ ██ ██████ ████████ ██████
-->
<section>
<h2 id="script-interfaces">Script Interfaces</h2>
<section>
<h3 id="securitypolicyviolationevent-interface">
<code>SecurityPolicyViolationEvent</code> Interface
</h3>
<pre class="idl">
[Constructor(DOMString type, optional SecurityPolicyViolationEventInit eventInitDict)]
interface SecurityPolicyViolationEvent : Event {
readonly attribute DOMString documentURI;
readonly attribute DOMString referrer;
readonly attribute DOMString blockedURI;
readonly attribute DOMString violatedDirective;
readonly attribute DOMString effectiveDirective;
readonly attribute DOMString originalPolicy;
readonly attribute DOMString sourceFile;
readonly attribute DOMString statusCode;
readonly attribute long lineNumber;
readonly attribute long columnNumber;
};
</pre>
<dl dfn-for="SecurityPolicyViolationEvent">
<dt><dfn attribute>documentURI</dfn></dt>
<dd>Refer to the <a href="#violation-report-document-uri"><code>document-uri</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn attribute>referrer</dfn></dt>
<dd>Refer to the <a href="#violation-report-referrer"><code>referrer</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn attribute>blockedURI</dfn></dt>
<dd>Refer to the <a href="#violation-report-blocked-uri"><code>blocked-uri</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn attribute>violatedDirective</dfn></dt>
<dd>Refer to the <a href="#violation-report-violated-directive"><code>violated-directive</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn attribute>effectiveDirective</dfn></dt>
<dd>Refer to the <a href="#violation-report-effective-directive"><code>effective-directive</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn attribute>originalPolicy</dfn></dt>
<dd>Refer to the <a href="#violation-report-original-policy"><code>original-policy</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn attribute>statusCode</dfn></dt>
<dd>Refer to the <a href="#violation-report-status-code"><code>status-code</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn attribute>sourceFile</dfn></dt>
<dd>Refer to the <a href="#violation-report-source-file"><code>source-file</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn attribute>lineNumber</dfn></dt>
<dd>Refer to the <a href="#violation-report-line-number"><code>line-number</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn attribute>columnNumber</dfn></dt>
<dd>Refer to the <a href="#violation-report-column-number"><code>column-number</code></a> property of violation reports for a description of this property.</dd>
</dl>
</section>
<section>
<h3 id="securitypolicyviolationeventinit-interface">
<code>SecurityPolicyViolationEventInit</code> Interface
</h3>
<pre class="idl">
dictionary SecurityPolicyViolationEventInit : EventInit {
DOMString documentURI;
DOMString referrer;
DOMString blockedURI;
DOMString violatedDirective;
DOMString effectiveDirective;
DOMString originalPolicy;
DOMString sourceFile;
long lineNumber;
long columnNumber;
};
</pre>
<dl dfn-for="SecurityPolicyViolationEventInit">
<dt><dfn dict-member>documentURI</dfn></dt>
<dd>Refer to the <a href="#violation-report-document-uri"><code>document-uri</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn dict-member>referrer</dfn></dt>
<dd>Refer to the <a href="#violation-report-referrer"><code>referrer</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn dict-member>blockedURI</dfn></dt>
<dd>Refer to the <a href="#violation-report-blocked-uri"><code>blocked-uri</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn dict-member>violatedDirective</dfn></dt>
<dd>Refer to the <a href="#violation-report-violated-directive"><code>violated-directive</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn dict-member>effectiveDirective</dfn></dt>
<dd>Refer to the <a href="#violation-report-effective-directive"><code>effective-directive</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn dict-member>originalPolicy</dfn></dt>
<dd>Refer to the <a href="#violation-report-original-policy"><code>original-policy</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn dict-member>sourceFile</dfn></dt>
<dd>Refer to the <a href="#violation-report-source-file"><code>source-file</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn dict-member>lineNumber</dfn></dt>
<dd>Refer to the <a href="#violation-report-line-number"><code>line-number</code></a> property of violation reports for a description of this property.</dd>
<dt><dfn dict-member>columnNumber</dfn></dt>
<dd>Refer to the <a href="#violation-report-column-number"><code>column-number</code></a> property of violation reports for a description of this property.</dd>
</dl>
</section>
<section>
<h3 id="firing-securitypolicyviolationevent-events">Firing Violation Events</h3>
To <dfn>fire a violation event</dfn>, the user agent MUST use an algorithm
equivalent to the following:
<ol>
<li>Let <var>report object</var> be the result of <a>generating a
violation report object</a>.</li>
<li><a spec="HTML5">Queue a task</a> to
<a lt="firing" spec="HTML5">fire an event</a> named
<code>securitypolicyviolation</code> using the
<code><a interface>SecurityPolicyViolationEvent</a></code> interface
with the following initializations:
<ul>
<li><code>blockedURI</code> MUST be initialized to the value of
<var>report object</var>'s <code>blocked-uri</code> key.</li>
<li><code>documentURI</code> MUST be initialized to the value of
<var>report object</var>'s <code>document-uri</code> key.</li>
<li><code>effectiveDirective</code> MUST be initialized to the value of
<var>report object</var>'s <code>effective-directive</code> key.</li>
<li><code>originalPolicy</code> MUST be initialized to the value of
<var>report object</var>'s <code>original-policy</code> key.</li>
<li><code>referrer</code> MUST be initialized to the value of
<var>report object</var>'s <code>referrer</code> key.</li>
<li><code>violatedDirective</code> MUST be initialized to the value of
<var>report object</var>'s <code>violated-directive</code> key.</li>
<li><code>sourceFile</code> MUST be initialized to the value of
<var>report object</var>'s <code>source-file</code> key.</li>
<li><code>lineNumber</code> MUST be initialized to the value of
<var>report object</var>'s <code>line-number</code> key.</li>
<li><code>columnNumber</code> MUST be initialized to the value of
<var>report object</var>'s <code>column-number</code> key.</li>
</ul>
</li>
</ol>
The <a spec="HTML5">task source</a> for these <a spec="HTML5">tasks</a>
is the <a>Content Security Policy task source</a>.
</section>
</section>
<!--
████████ ████ ████████ ████████ ██████ ████████ ████ ██ ██ ████████ ██████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ████████ ██████ ██ ██ ██ ██ ██ ██████ ██████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
████████ ████ ██ ██ ████████ ██████ ██ ████ ███ ████████ ██████
-->
<section>
<h2 id="directives">Directives</h2>
This section describes the content security policy directives
introduced in this specification. Directive names are case insensitive.
In order to protect against Cross-Site Scripting (XSS), web
application authors SHOULD include:
<ul>
<li>both the <code><a>script-src</a></code> and
<code><a>object-src</a></code> directives, or</li>
<li>include a <code><a>default-src</a></code> directive, which covers both
scripts and plugins.</li>
</ul>
In either case, authors SHOULD NOT include either
<code>'unsafe-inline'</code> or <code>data:</code> as valid sources in
their policies. Both enable XSS attacks by allowing code to be included
directly in the document itself; they are best avoided completely.
<!--
████████ ███ ██████ ████████ ██ ██ ████████ ████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
████████ ██ ██ ██████ ██████ ███████ ██ ██ ████████ ██
██ ██ █████████ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
████████ ██ ██ ██████ ████████ ███████ ██ ██ ████
-->
<section>
<h3 id="directive-base-uri"><code>base-uri</code></h3>
The <code><dfn>base-uri</dfn></code> directive restricts the URLs that can
be used to specify the <a spec="HTML5">document base URL</a>. The syntax for
the name and value of the directive are described by the following ABNF
grammar:
<pre>
directive-name = "base-uri"
directive-value = <a>source-list</a>
</pre>
The term <dfn>allowed base URLs</dfn> refers to the result of
<a lt="parse a source list">parsing the <code>base-uri</code> directive's
value as a source list</a>.
Note: <code>base-uri</code> does not fall back to the <a>default
sources</a>.
Step 4 of the algorithm defined in HTML5 to obtain a
<em>document's base URL</em> (resolution of the <code>href</code> attribute
of the <code>base</code> element) MUST be changed to:
<ol start="4">
<li>If the previous step was not successful, or the result of the
previous step does not <a lt="match a source list">match</a>
the <a>allowed base URLs</a> for the <a>protected resource</a>, then the
<a spec="HTML5">document base URL</a> is <var>fallback base URL</var>.
Otherwise, it is the result of the previous step.</li>
</ol>
</section>
<!--
██████ ██ ██ ████ ██ ████████ ██████ ████████ ██████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ █████████ ██ ██ ██ ██ ███████ ██████ ████████ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██████ ██ ██ ████ ████████ ████████ ██████ ██ ██ ██████
-->
<section>
<h3 id="directive-child-src"><code>child-src</code></h3>
The <code><dfn>child-src</dfn></code> directive governs the creation of
<a spec="HTML5">nested browsing contexts</a> as well as Worker execution
contexts. The syntax for the name and value of the directive are described
by the following ABNF grammar:
<pre>
directive-name = "child-src"
directive-value = <a>source-list</a>
</pre>
The term <dfn>allowed child sources</dfn> refers to the result of
<a lt="parse a source list">parsing the <code>child-src</code>
directive's value as a source list</a> if a <code>child-src</code>
directive is explicitly specified, and otherwise to the
<a>default sources</a>.
<section>
<h4 id="directive-child-src-nested">Nested Browsing Contexts</h4>
To enforce the <code>child-src</code> directive the user agent MUST
enforce the <code><a>frame-src</a></code> directive.
</section>
<section>
<h4 id="directive-child-src-workers">Workers</h4>
Whenever the user agent <a>fetches</a> a URL while processing the
<code>Worker</code> or <code>SharedWorker</code> constructors
[[!WORKERS]], the user agent MUST act as if there was a fatal network
error and no resource was obtained, <em>and</em> <a>report a violation</a>
if the URL does not <a lt="match a source list">match</a> the
<a>allowed child sources</a> for the <a>protected resource</a>.
</section>
</section>
<!--
██████ ███████ ██ ██ ██ ██ ████████ ██████ ████████ ██████ ████████ ██████
██ ██ ██ ██ ███ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ████ ██ ████ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██████ ██ ██ ███████ ██████ ████████ ██
██ ██ ██ ██ ████ ██ ████ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ███ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██████ ███████ ██ ██ ██ ██ ████████ ██████ ██ ██████ ██ ██ ██████
-->
<section>
<h3 id="directive-connect-src"><code>connect-src</code></h3>
The <code><dfn>connect-src</dfn></code> directive restricts which URLs the
protected resource can load using script interfaces. The syntax for the name
and value of the directive are described by the following ABNF grammar:
<pre>
directive-name = "connect-src"
directive-value = <a>source-list</a>
</pre>
The term <dfn>allowed connection targets</dfn> refers to the result of
<a lt="parse a source list">parsing the <code>connect-src</code>
directive's value as a source list</a> if the policy contains an
explicit <code>connect-src</code> directive, or otherwise to the
<a>default sources</a>.
Whenever the user agent <a>fetches</a> a URL in the course of one of the
following activities, if the URL does not
<a lt="match a source list">match</a> the <a>allowed connection
targets</a> for the <a>protected resource</a>, the user agent MUST act as
if there was a fatal network error and no resource was obtained,
<em>and</em> <a>report a violation</a>:
<ul>
<!-- TODO: Figure out how to autolink here. -->
<li>Processing the <a
href="http://www.w3.org/TR/XMLHttpRequest/#the-send()-method"><code>send()</code>
method</a> of an <code>XMLHttpRequest</code> object.</li>
<li>Processing the <a
href="http://dev.w3.org/html5/websockets/#websocket"><code>WebSocket</code>
constructor</a>.</li>
<li>Processing the <a
href="http://dev.w3.org/html5/eventsource/#eventsource"><code>EventSource</code>
constructor</a>.</li>
<li>Pinging an endpoint during <a href="https://html.spec.whatwg.org/multipage/semantics.html#hyperlink-auditing">hyperlink auditing</a>.</li>
<li>Sending a beacon via the <a href="http://www.w3.org/TR/beacon/#sec-sendBeacon-method"><code>sendBeacon()</code></a> method. [[!BEACON]]</li>
</ul>
<section class="informative">
<h4 id="connect-src-usage">Usage</h4>
<em>This section is not normative.</em>
JavaScript offers a few mechanisms that directly connect to an
external server to send or receive information. <code>EventSource</code>
maintains an open HTTP connection to a server in order to receive push
notifications, <code>WebSockets</code> open a bidirectional communication
channel between your browser and a server, and <code>XMLHttpRequest</code>
allows arbitrary HTTP requests. These are powerful APIs that
enable useful functionality, but also provide tempting avenues for data
exfiltration.
The <code>connect-src</code> directive allows restricting these sorts of
connections to the those matching the source expressions list.
Sending a policy that defines a list of source expressions for this
directive is straightforward. For example, to limit connections to
only <code>example.com</code>, send the following header:
<pre>Content-Security-Policy: <a>connect-src</a> example.com</pre>
Each of the following will fail with the preceding directive in
place:
<ul>
<li><code>new WebSocket("wss://evil.com/");</code></li>
<li><code>(new XMLHttpRequest()).open("GET", "https://evil.com/", true);</code></li>
<li><code>new EventSource("https://evil.com");</code></li>
</ul>
</section>
</section>
<!--
████████ ████████ ████████ ███ ██ ██ ██ ████████ ██████ ████████ ██████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██████ ██████ ██ ██ ██ ██ ██ ██ ███████ ██████ ████████ ██
██ ██ ██ ██ █████████ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
████████ ████████ ██ ██ ██ ███████ ████████ ██ ██████ ██ ██ ██████
-->
<section>
<h3 id="directive-default-src"><code>default-src</code></h3>
The <code><dfn>default-src</dfn></code> directive sets a default
source list for a number of directives. The syntax for the name and
value of the directive are described by the following ABNF grammar:
<pre>
directive-name = "default-src"
directive-value = <a>source-list</a>
</pre>
Let the <dfn>default sources</dfn> be the result of
<a lt="parse a source list">parsing the <code>default-src</code>
directive's value as a source list</a> if a <code>default-src</code>
directive is explicitly specified, and otherwise a list including all
possible sources.
To enforce the <code>default-src</code> directive, the user agent
MUST enforce the following directives:
<ul>
<li><code><a>child-src</a></code></li>
<li><code><a>connect-src</a></code></li>
<li><code><a>font-src</a></code></li>
<li><code><a>img-src</a></code></li>
<li><code><a>media-src</a></code></li>
<li><code><a>object-src</a></code></li>
<li><code><a>script-src</a></code></li>
<li><code><a>style-src</a></code></li>
</ul>
If not specified explicitly in the policy, the directives listed
above will use the <a>default sources</a> as their source list.
<section>
<h4 id="default-src-usage">Usage</h4>
<em>This section is not normative.</em>
<code>default-src</code>, as the name implies, serves as a default
source list which the other source list-style directives will use as
a fallback if they're not otherwise explicitly set. That is, consider
the following policy declaration:
<pre>Content-Security-Policy: <a>default-src</a> 'self'</pre>
Under this policy, fonts, frames, images, media, objects, scripts,
and styles will all only load from the same origin as the protected
resource, and connections will only be made to the same origin. Adding
a more specific declaration to the policy would completely override
the default source list for that resource type.
<pre>Content-Security-Policy: <a>default-src</a> 'self'; <a>script-src</a> example.com</pre>
Under this new policy, fonts, frames, and etc. continue to be load
from the same origin, but scripts will <em>only</em> load from
<code>example.com</code>. There's no inheritance; the
<code><a>script-src</a></code> directive sets the allowed sources of
script, and the default list is not used for that resource type.
Given this behavior, one good way of building a policy for a site
would be to begin with a <code>default-src</code> of
<code>'none'</code>, and to build up a policy from there that contains
only those resource types which are actually in use for the page you'd
like to protect. If you don't use webfonts, for instance, there's no
reason to specify a source list for <code><a>font-src</a></code>;
specifying only those resource types a page uses ensures that the
possible attack surface for that page remains as small as possible.
</section>
</section>
<!--
████████ ███████ ██ ██ ████████ ██████ ████████ ██████
██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ████ ██ ██ ██ ██ ██ ██
██████ ██ ██ ██ ██ ██ ██ ███████ ██████ ████████ ██
██ ██ ██ ██ ████ ██ ██ ██ ██ ██
██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██
██ ███████ ██ ██ ██ ██████ ██ ██ ██████
-->
<section>
<h3 id="directive-font-src"><code>font-src</code></h3>
The <code><dfn>font-src</dfn></code> directive restricts from where the
protected resource can load fonts. The syntax for the name and value
of the directive are described by the following ABNF grammar:
<pre>
directive-name = "font-src"
directive-value = <a>source-list</a>
</pre>
The term <dfn>allowed font sources</dfn> refers to the result of
<a lt="parse a source list">parsing the <code>font-src</code>
directive's value as a source list</a> if the policy contains an
explicit <code>font-src</code>, or otherwise to the
<a>default sources</a>.
Whenever the user agent <a>fetches</a> a URL in the course of one of the
following activities, if the URL does not
<a lt="match a source list">match</a> the <a>allowed font sources</a>
for the <a>protected resource</a>, the user agent MUST act as if there was
a fatal network error and no resource was obtained, <em>and</em> <a>report
a violation</a>:
<ul>
<li>Requesting data for display in a font, such as when processing
the <<@font-face>> Cascading Style Sheets (CSS) rule.</li>
</ul>
</section>
<!--
████████ ███████ ████████ ██ ██ ███ ██████ ████████ ████ ███████ ██ ██
██ ██ ██ ██ ██ ███ ███ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██
██ ██ ██ ██ ██ ████ ████ ██ ██ ██ ██ ██ ██ ██ ████ ██
██████ ██ ██ ████████ ██ ███ ██ ███████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ █████████ ██ ██ ██ ██ ██ ██ ████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███
██ ███████ ██ ██ ██ ██ ██ ██ ██████ ██ ████ ███████ ██ ██
-->
<section>
<h3 id="directive-form-action"><code>form-action</code></h3>
The <code><dfn>form-action</dfn></code> restricts which URLs can be used as
the action of HTML <{form}> elements. The syntax for the name and value of
the directive are described by the following ABNF grammar:
<pre>
directive-name = "form-action"
directive-value = <a>source-list</a>
</pre>
The term <dfn>allowed form actions</dfn> refers to the result of
<a lt="parse a source list">parsing the <code>form-action</code>
directive's value as a source list</a>.
Whenever the user agent <a>fetches</a> a URL in the course of processing
an HTML <{form}> element, if the URL does not
<a lt="match a source list">match</a> the <a>allowed form actions</a> for
the <a>protected resource</a>, the user agent MUST act as if there was a
fatal network error and no resource was obtained, <em>and</em> <a>report a
violation</a>.
Note: <code>form-action</code> does not fall back to the <a>default
sources</a> when the directive is not defined. That is, a policy that
defines <code><a>default-src</a> 'none'</code> but not
<code>form-action</code> will still allow form submissions to any
target.
</section>
<!--
████████ ████████ ███ ██ ██ ████████ ███ ██ ██ ██████ ████████ ██████ ████████ ███████ ████████ ██████
██ ██ ██ ██ ██ ███ ███ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ████ ████ ██ ██ ██ ████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██████ ████████ ██ ██ ██ ███ ██ ██████ ███████ ██ ██ ██ ██ ██ ██ ██████ ██████ ██ ██ ██ ████████ ██████
██ ██ ██ █████████ ██ ██ ██ █████████ ██ ████ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ████████ ██ ██ ██ ██ ██████ ████████ ██████ ██ ███████ ██ ██ ██████
-->
<section>
<h3 id="directive-frame-ancestors"><code>frame-ancestors</code></h3>
The <code><dfn>frame-ancestors</dfn></code> directive indicates whether the
user agent should allow embedding the resource using a <{frame}>,
<{iframe}>, <{object}>, <{embed}> or <{applet}> element, or equivalent
functionality in non-HTML resources. Resources can use this directive to
avoid many UI Redressing attacks by avoiding being embedded
into potentially hostile contexts.
The syntax for the name and value of the directive are described by the
following ABNF grammar:
<pre>
<dfn>ancestor-source-list</dfn> = [ <a>ancestor-source</a> *( 1*WSP <a>ancestor-source</a> ) ] / "'none'"
<dfn>ancestor-source</dfn> = <a>scheme-source</a> / <a>host-source</a> / "'self'"
directive-name = "frame-ancestors"
directive-value = <a>ancestor-source-list</a>
</pre>
The term <dfn>allowed frame ancestors</dfn> refers to the result of
<a lt="parse a source list">parsing the <code>frame-ancestors</code>
directive's value as a source list</a>. If a <code>frame-ancestors</code>
directive is not explicitly included in the policy, then <a>allowed frame
ancestors</a> is "<code>*</code>".
To enforce the <code>frame-ancestors</code> directive, whenever the
user agent would load the protected resource into a <a>nested browsing
context</a>, the user agent MUST perform the following steps:
<ol>
<li>Let <var>nestedContext</var> be the nested browsing context into
which the protected resource is being loaded.</li>
<li>Let <var>ancestorList</var> be the list of all
<a lt="ancestor browsing context">ancestors</a> of <var>nestedContext</var>.</li>
<li>For each <var>ancestorContext</var> in <var>ancestorList</var>:
<ol>
<li>Let <var>document</var> be <var>ancestorContext</var>'s
<a spec="HTML5">active document</a>.</li>
<li>If <var>document</var>'s URL does not
<a lt="match a source list">match</a> the <a>allowed frame
ancestors</a> for the <a>protected resource</a>, the user agent MUST:
<ol>
<li>Abort loading the protected resource.</li>
<li>Take one of the following actions:
<ul>
<li>
Act as if it received an empty <a>HTTP 200 response</a>.
</li>
<li>
Redirect the user to a friendly error page which provides
the option of opening the blocked page in a new <a>top-level
browsing context</a>.
</li>
</ul>
</li>
<li>
<a spec="HTML5">Parse a sandboxing directive</a> using the
empty string as the <em>input</em> and the newly created
document's <a spec="HTML5">forced sandboxing flag set</a> as the
<em>output</em>.
</li>
<li><a>Report a violation</a>.</li>
<li>Abort these steps.</li>
</ol>
</li>
</ol>
</li>
</ol>
Steps 3.2.2 and 3.2.3 ensure that the blocked frame appears to be a
normal cross-origin document's load. If these steps are ignored,
leakage of a document's policy state is possible.
The <code>frame-ancestors</code> directive MUST be ignored
when <a>monitoring</a> a policy, and when a contained in a
policy defined via a <{meta}> element.
Note: <code><a>frame-ancestors</a></code> does not fall back to the
<a>default sources</a> when the directive is not defined. That is, a policy
that defines <code><a>default-src</a> 'none'</code> but not
<code>frame-ancestors</code> will still allow the resource to be framed from
anywhere.
When generating a violation report for a <code>frame-ancestors</code>
violation, the user agent MUST NOT include the value of the embedding
ancestor as a <code>blocked-uri</code> value unless it is same-origin with
the protected resource, as disclosing the value of cross-origin ancestors
is a violation of the Same-Origin Policy.
<section>
<h4 id="frame-ancestors-and-frame-options">
Relation to <code>X-Frame-Options</code>
</h4>
This directive is similar to the <code>X-Frame-Options</code> header that
several user agents have implemented. The <code>'none'</code> source
expression is roughly equivalent to that header's <code>DENY</code>,
<code>'self'</code> to <code>SAMEORIGIN</code>, and so on. The major
difference is that many user agents implement <code>SAMEORIGIN</code> such
that it only matches against the top-level document's location. This
directive checks each ancestor. If any ancestor doesn't match, the load
is cancelled. [[!RFC7034]]
The <code>frame-ancestors</code> directive <em>obsoletes</em> the
<code>X-Frame-Options</code> header. If a resource has both policies,
the <code>frame-ancestors</code> policy SHOULD be enforced and the
<code>X-Frame-Options</code> policy SHOULD be ignored.
</section>
<section id="multiple-host-source-values" class="informative">
<h4 id="frame-ancestors-multiple-source-values">Multiple Host Source Values</h4>
<em>This section is not normative.</em>
Multiple source-list expressions are allowed in a single policy (in contrast
to <code>X-Frame-Options</code>, which allows only one) to enable
scenarios involving embedded application components that are multiple levels
below the top-level browsing context.
Many common scenarios for embedding (e.g. embeddable payment,
sharing or social apps) involve potentially many hundreds or thousands of
valid <code>source-list</code> expressions, but it is strongly recommended
against accommodating such scenarios with a static
<code>frame-ancestors</code> directive listing multiple values. In such
cases it is beneficial to generate this value dynamically, based on an
HTTP Referer header or an explicitly passed-in value, to allow only the
sources necessary for each given embedding of the resource.
Consider a service providing a payments application at
<code>https://payments/makeEmbedded</code>. The service allows this resource
to be embedded by both merchant Alice and merchant Bob, who compete with each
other. Sending:
<pre>
Content-Security-Policy: <a>frame-ancestors</a> https://alice https://bob
</pre>
would allow Bob to re-frame Alice's resource and create fraudulent clicks,
perhaps discrediting Alice with her customers or the payments service. If the
payments service used additional information (e.g. as part of a URL like
<code>https://payments/makeEmbedded?merchant=alice</code>) to send
individually-tailored headers listing only the source-list expressions
needed by each merchant, this attack would be eliminated.
</section>
</section>
<!--
████████ ████████ ███ ██ ██ ████████ ██████ ████████ ██████
██ ██ ██ ██ ██ ███ ███ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ████ ████ ██ ██ ██ ██ ██
██████ ████████ ██ ██ ██ ███ ██ ██████ ███████ ██████ ████████ ██
██ ██ ██ █████████ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ████████ ██████ ██ ██ ██████
-->
<section>
<h3 id="directive-frame-src"><code>frame-src</code></h3>
The <code><dfn>frame-src</dfn></code> directive is <em>deprecated</em>.
Authors who wish to govern nested browsing contexts SHOULD use the
<code>child-src</code> directive instead.
The <code>frame-src</code> directive restricts from where the
protected resource can embed frames. The syntax for the name
and value of the directive are described by the following ABNF
grammar:
<pre>
directive-name = "frame-src"
directive-value = <a>source-list</a>
</pre>
The term <dfn>allowed frame sources</dfn> refers to the result of
<a lt="parse a source list">parsing the <code>frame-src</code>
directive's value as a source list</a> if the policy contains an
explicit <code>frame-src</code>, or otherwise to the list of
<a>allowed child sources</a>.
Whenever the user agent <a>fetches</a> a URL in the course of one of the
following activities, if the URL does not
<a lt="match a source list">match</a> the <a>allowed frame sources</a>
for the <a>protected resource</a>, the user agent MUST act as if there was a
fatal network error and no resource was obtained, <em>and</em> <a>report a
violation</a>:
<ul>
<li>Requesting data for display in a <a>nested browsing context</a> in the
protected resource created by an <{iframe}> or a <{frame}> element.
<li><a spec="HTML5">Navigated</a> such a <a>nested browsing context</a>.</li>
</ul>
</section>
<!--
████ ██ ██ ██████ ██████ ████████ ██████
██ ███ ███ ██ ██ ██ ██ ██ ██ ██ ██
██ ████ ████ ██ ██ ██ ██ ██
██ ██ ███ ██ ██ ████ ███████ ██████ ████████ ██
██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
████ ██ ██ ██████ ██████ ██ ██ ██████
-->
<section>
<h3 id="directive-img-src"><code>img-src</code></h3>
The <code><dfn>img-src</dfn></code> directive restricts from where the
protected resource can load images. The syntax for the name and value
of the directive are described by the following ABNF grammar:
<pre>
directive-name = "img-src"
directive-value = <a>source-list</a>
</pre>
The term <dfn>allowed image sources</dfn> refers to the result of
<a lt="parse a source list">parsing the <code>img-src</code>
directive's value as a source list</a> if the policy contains an
explicit <code>img-src</code>, or otherwise to the list of
<a>default sources</a>.
Whenever the user agent <a>fetches</a> a URL in the course of one of the
following activities, if the URL does not
<a lt="match a source list">match</a> the <a>allowed image sources</a>
for the <a>protected resource</a>, the user agent MUST act as if there was a
fatal network error and no resource was obtained, <em>and</em> <a>report a
violation</a>:
<ul>
<!-- TODO: autolink srcset -->
<li>Requesting data for an image, such as when processing the
<{img/src}> or <code>srcset</code> attributes of an <{img}> element, the
<{input/src}> attribute of an <{input}> element with a type of
<{input/image}>, the <{video/poster}> attribute of a <{video}> element,
the <a>url()</a>, <a>image()</a> or <a>image-set()</a> values on any
Cascading Style Sheets (CSS) property that is capable of loading an image
[[!CSS4-IMAGES]], or the <{link/href}> attribute of a <{link}> element
with an image-related <{link/rel}> attribute, such as <{link/icon}>.</li>
</ul>
</section>
<!--
██ ██ ████████ ████████ ████ ███ ██████ ████████ ██████
███ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
████ ████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ███ ██ ██████ ██ ██ ██ ██ ██ ███████ ██████ ████████ ██
██ ██ ██ ██ ██ ██ █████████ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ████████ ████████ ████ ██ ██ ██████ ██ ██ ██████
-->
<section>
<h3 id="directive-media-src"><code>media-src</code></h3>
The <code><dfn>media-src</dfn></code> directive restricts from where the
protected resource can load video, audio, and associated text tracks.
The syntax for the name and value of the directive are described by the
following ABNF grammar:
<pre>
directive-name = "media-src"
directive-value = <a>source-list</a>
</pre>
The term <dfn>allowed media sources</dfn> refers to the result of
<a lt="parse a source list">parsing the <code>media-src</code>
directive's value as a source list</a> if the policy contains an
explicit <code>media-src</code>, or otherwise to the list of
<a>default sources</a>.
Whenever the user agent <a>fetches</a> a URL in the course of one of the
following activities, if the URL does not
<a lt="match a source list">match</a> the <a>allowed media sources</a>
for the <a>protected resource</a>, the user agent MUST act as if there was
a fatal network error and no resource was obtained, <em>and</em> <a>report
a violation</a>:
<ul>
<li>Requesting data for a video or audio clip, such as when processing the
<{video/src}> attribute of a <{video}>, <{audio}>, <{source}>, or
<{track}> element.</li>
</ul>
</section>
<!--
███████ ████████ ██ ████████ ██████ ████████ ██████ ████████ ██████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ████████ ██ ██████ ██ ██ ███████ ██████ ████████ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
███████ ████████ ██████ ████████ ██████ ██ ██████ ██ ██ ██████
-->
<section>
<h3 id="directive-object-src"><code>object-src</code></h3>
The <code><dfn>object-src</dfn></code> directive restricts from where
the protected resource can load plugins. The syntax for the name and value
of the directive are described by the following ABNF grammar:
<pre>
directive-name = "object-src"
directive-value = <a>source-list</a>
</pre>
The term <dfn>allowed object sources</dfn> refers to the result of
<a lt="parse a source list">parsing the <code>object-src</code>
directive's value as a source list</a> if the policy contains an
explicit <code>object-src</code>, or otherwise to the list of
<a>default sources</a>.
Whenever the user agent <a>fetches</a> a URL in the course of one of the
following activities, if the URL does not
<a lt="match a source list">match</a> the <a>allowed object sources</a>
for the <a>protected resource</a>, the user agent MUST act as if there was a
fatal network error and no resource was obtained, <em>and</em> <a>report a
violation</a>:
<ul>
<li>Requesting data for a plugin, such as when processing the
<{object/data}> attribute of an <{object}> element, the <{embed/src}>
attribute of an <{embed}> element, or the <{applet/code}> or
<{applet/archive}> attributes of an <{applet}> element.</li>
<li>Requesting data for display in a <a>nested browsing context</a>
in the protected resource created by an <{object}> or an <{embed}>
element.</li>
<li>Navigating such a <a>nested browsing context</a>.</li>
</ul>
It is not required that the consumer of the element's data be a
<a>plugin</a> in order for the <code>object-src</code> directive to be
enforced. Data for any <{object}>, <{embed}>, or <{applet}> element MUST
match the <a>allowed object sources</a> in order to be fetched. This is true
even when the element data is semantically equivalent to content which would
otherwise be restricted by one of the other [[#directives]], such as an
<{object}> element with a <code>text/html</code> MIME type.
Whenever the user agent would load a <a>plugin</a> without an associated
URL (e.g., because the <{object}> element lacked a <{object/data}>
attribute), if the protected resource's URL does not
<a lt="match a source list">match</a> the <a>allowed object sources</a>
for the <a>protected resource</a>, the user agent MUST NOT load the plugin.
</section>
<!--
████████ ██ ██ ██ ██████ ████ ██ ██ ████████ ██ ██ ████████ ████████ ██████
██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ████ ██ ██ ████ ██ ██ ██ ██
████████ ██ ██ ██ ██ ████ ██ ██ ██ ██ ███████ ██ ██ ████████ ██████ ██████
██ ██ ██ ██ ██ ██ ██ ██ ████ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██
██ ████████ ███████ ██████ ████ ██ ██ ██ ██ ██ ████████ ██████
-->
<section>
<h3 id="directive-plugin-types"><code>plugin-types</code></h3>
The <code><dfn>plugin-types</dfn></code> directive restricts the set
of plugins that can be invoked by the protected resource by limiting
the types of resources that can be embedded. The syntax for the name
and value of the directive are described by the following ABNF
grammar:
<pre>
directive-name = "plugin-types"
directive-value = media-type-list
</pre>
The term <dfn>allowed plugin media types</dfn> refers to the result of
<a lt="parse a media type list">parsing the <code>plugin-types</code>
directive's value as a media type list</a>.
Whenever the user agent would instantiate a <a>plugin</a>
to handle <var>resource</var> while enforcing the <code>plugin-types</code>
directive, the user agent MUST instead act as though the plugin reported an
error <em>and</em> <a>report a violation</a> if any of the following
conditions hold:
<ul>
<li>The plugin is embedded into the protected resource via an
<{object}> or <{embed}> element that does not explicitly
declare a <a spec="HTML5">MIME type</a> via a <{object/type}>
attribute.</li>
<li><var>resource</var>'s media type does not
<a lt="match a media type list">match</a> the list of <a>allowed
plugin media types</a>.</li>
<li>The plugin is embedded into the protected resource via an
<{object}> or <{embed}> element, and the media type declared
in the element's <{object/type}> attribute is not an <a>ASCII
case-insensitive match</a> for the <var>resource</var>'s media
type.</li>
<li>The plugin is embedded into the protected resource via an
<{applet}> element, and <var>resource</var>'s media type is not an
<a>ASCII case-insensitive match</a> for
<code>application/x-java-applet</code>.</li>
</ul>
Note: In any of these cases, acting as though the plugin reported an
error will cause the user agent to display the <a spec="HTML5">fallback
content</a>.
Whenever the user agent creates a <a spec="HTML5">plugin document</a> as the
<a>active document</a> of a <a>child browsing context</a> of the
<a>protected resource</a>, if the user agent is enforcing any
<code>plugin-types</code> directives for the protected resource, the user
agent MUST <a>enforce</a> those <code>plugin-types</code> directives on the
plugin document as well.
Whenever the user agent creates a <a spec="HTML5">plugin document</a> as the
<a>active document</a> of a <a>child browsing context</a> of the
<a>protected resource</a>, if the user agent is monitoring any
<code>plugin-types</code> directives for the protected resource, the user
agent MUST <a>monitor</a> those <code>plugin-types</code> directives on the
plugin document as well.
<section class="informative">
<h4 id="plugin-types-usage">Usage</h4>
<em>This section is not normative.</em>
The <code>plugin-types</code> directive whitelists a certain set
of MIME types that can be embedded in a protected resource. For
example, a site might want to ensure that PDF content loads, but that
no other plugins can be instantiated. The following directive would
satisfy that requirement:
<pre>Content-Security-Policy: <a>plugin-types</a> application/pdf</pre>
Resources embedded via an <code><a element>embed</a></code> or
<code><a element>object</a></code> element delivered with an
<code>application/pdf</code> content type would be rendered in the
appropriate plugin; resources delivered with some other content type
would be blocked. Multiple types can be specified, in any order. If the
site decided to additionally allow Flash at some point in the future, it
could do so with the following directive:
<pre>Content-Security-Policy: <a>plugin-types</a> application/pdf application/x-shockwave-flash</pre>
Note: Wildcards are not accepted in the <code>plugin-types</code>
directive. Only the resource types explicitly listed in the directive
will be allowed.
</section>
<section class="informative">
<h4 id="plugin-types-predeclaration">
Predeclaration of expected media types
</h4>
<em>This section is not normative.</em>
Enforcing the <code>plugin-types</code> directive requires that
<code><a element>object</a></code> and <code><a element>embed</a></code>
elements declare the expected media type of the resource they include via
the <code><a element-attr>type</a></code> attribute. If an author expects
to load a PDF, she could specify this as follows:
<pre><object data="<var>resource</var>" type="application/pdf"></object></pre>
If <var>resource</var> isn't actually a PDF file, it won't
load. This prevents certain types of attacks that rely on serving
content that unexpectedly invokes a plugin other than that which the
author intended.
Note: <var>resource</var> will not load in this scenario even
if its media type is otherwise whitelisted: resources will only load
when their media type is whitelisted <em>and</em> matches the
declared type in their containing element.
</section>
</section>
<!--
████████ ████████ ████████ ███████ ████████ ████████ ██ ██ ████████ ████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
████████ ██████ ████████ ██ ██ ████████ ██ ███████ ██ ██ ████████ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ████████ ██ ███████ ██ ██ ██ ███████ ██ ██ ████
-->
<section>
<h3 id="directive-report-uri"><code>report-uri</code></h3>
The <code><dfn>report-uri</dfn></code> directive specifies a URL to
which the user agent sends reports about policy violation. The syntax
for the name and value of the directive are described by the following
ABNF grammar:
<pre>
directive-name = "report-uri"
directive-value = <a>uri-reference</a> *( 1*WSP <a>uri-reference</a> )
<dfn>uri-reference</dfn> = <URI-reference from RFC 3986>
</pre>
The <dfn>set of report URLs</dfn> is the value of the
<code>report-uri</code> directive, each resolved relative to the
protected resource's URL.
The process of sending violation reports to the URLs specified in
this directive's value is defined in this document's
<a section href="#violation-reports"></a> section.
Note: The <code>report-uri</code> directive will be ignored if contained
within a <a href="#delivery-html-meta-element"><code>meta</code>
element</a>.
</section>
<!--
██████ ███ ██ ██ ████████ ████████ ███████ ██ ██
██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ████ ██ ██ ██ ██ ██ ██ ██ ██ ██
██████ ██ ██ ██ ██ ██ ██ ██ ████████ ██ ██ ███
██ █████████ ██ ████ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██
██████ ██ ██ ██ ██ ████████ ████████ ███████ ██ ██
-->
<section>
<h3 id="directive-sandbox"><code>sandbox</code></h3>
The <code><dfn>sandbox</dfn></code> directive specifies an HTML
sandbox policy that the user agent applies to the protected resource.
The syntax for the name and value of the directive are described by
the following ABNF grammar:
<pre>
directive-name = "sandbox"
directive-value = "" / sandbox-token *( 1*WSP <a>sandbox-token</a> )
<dfn>sandbox-token</dfn> = <token from RFC 7230>
</pre>
When enforcing the <code>sandbox</code> directive, the user agent
MUST <a spec="HTML5">parse a sandboxing directive</a> using the
<code>directive-value</code> as the <em>input</em> and protected
resource's <a spec="HTML5">forced sandboxing flag set</a>
as the output. [[!HTML5]]
The <code>sandbox</code> directive will be ignored when <a>monitoring</a>
a policy, and when contained in a policy defined via a
<a href="#delivery-html-meta-element"><code>meta</code> element</a>.
Moreover, this directive has no effect when <a>monitored</a>, and has no
reporting requirements.
<h4 id="sandboxing-and-workers">Sandboxing and Workers</h4>
When delivered via an HTTP header, a Content Security Policy may indicate
that sandboxing flags ought to be applied to a JavaScript execution
environment that is not a {{Document}}. Of particular interest is the
script content intended for use as a Worker, Shared Worker, or Service
Worker. Many of the sandboxing flags do not apply to such environments, but
<a element-attr for="iframe">allow-scripts</a> and
<a element-attr for="iframe">allow-same-origin</a> have special
requirements.
When a resource is loaded while executing the <a>runs a
<code>Worker</code></a> algorithm, the user agent MUST act as if there was
a fatal network error and no resource could be obtained if either of the
following conditions holds:
<ol>
<li>
The <code><a>sandbox</a></code> directive delivered with the resource
does <em>not</em> contain the
<a element-attr for="iframe">allow-scripts</a> flag.
</li>
<li>
The <code><a>sandbox</a></code> directive delivered with the resource
does <em>not</em> contain the
<a element-attr for="iframe">allow-same-origin</a> flag, <em>and</em>
the creation of the new execution context requires it to be same-origin
with its creating context.
</li>
</ol>
<section class="informative">
<h4 id="sandbox-usage">Usage</h4>
<em>This section is not normative.</em>
<p>HTML5 defines a <code><a element-attr>sandbox</a></code> attribute for
<code><a element>iframe</a></code> elements, intended to allow web authors
to reduce the risk of including potentially untrusted content by imposing
restrictions on that content's abilities. When the attribute is set,
the content is forced into a unique origin, prevented from submitting
forms, running script, creating or navigating other browsing contexts,
and prevented from running plugins. These restrictions can be loosened
by setting certain flags as the attribute's value.
The <code>sandbox</code> directive allows any resource, framed or
not, to ask for the same sorts of restrictions to be applied to
itself.
For example, a message board or email system might provide
downloads of arbitrary attachments provided by other users. Attacks
that rely on tricking a client into rendering one of these attachments
could be mitigated by requesting that resources only be rendered in a
very restrictive sandbox. Sending the <code>sandbox</code> directive
with an empty value establishes such an environment:
<pre>Content-Security-Policy: <a>sandbox</a></pre>
More trusted resources might be allowed to run in an environment
with fewer restrictions by adding <code>allow-*</code> flags to the
directive's value. For example, you can allow a page that you trust
to run script, while ensuring that it isn't treated as same-origin
with the rest of your site. This can be accomplished by sending the
<code>sandbox</code> directive with the
<code><a element-attr>allow-scripts</a></code> flag:
<pre>Content-Security-Policy: <a>sandbox</a> <a element-attr>allow-scripts</a></pre>
The set of flags available to the CSP directive should match those
available to the <code><a element>iframe</a></code> attribute.
Currently, those include:
<ul>
<li><code><a element-attr>allow-forms</a></code></li>
<li><code><a element-attr>allow-pointer-lock</a></code></li>
<li><code><a element-attr>allow-popups</a></code></li>
<li><code><a element-attr>allow-same-origin</a></code></li>
<li><code><a element-attr>allow-scripts</a></code></li>
<li><code><a element-attr>allow-top-navigation</a></code></li>
</ul>
Note: Like the rest of Content Security Policy, the <code>sandbox</code>
directive is meant as a defense-in-depth. Web authors would be well-served
to use it <em>in addition to</em> standard sniffing-mitigation and
privilege-reduction techniques.
</section>
</section>
<!--
██████ ██████ ████████ ████ ████████ ████████ ██████ ████████ ██████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██████ ██ ████████ ██ ████████ ██ ███████ ██████ ████████ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██████ ██████ ██ ██ ████ ██ ██ ██████ ██ ██ ██████
-->
<section>
<h3 id="directive-script-src"><code>script-src</code></h3>
The <code><dfn>script-src</dfn></code> directive restricts which scripts the
protected resource can execute. The directive also controls other resources,
such as XSLT style sheets [[!XSLT]], which can cause the user agent to
execute script. The syntax for the name and value of the directive are
described by the following ABNF grammar:
<pre>
directive-name = "script-src"
directive-value = <a>source-list</a>
</pre>
The term <dfn>allowed script sources</dfn> refers to the result of
<a lt="parse a source list">parsing the <code>script-src</code>
directive's value as a source list</a> if the policy contains an
explicit <code>script-src</code>, or otherwise to the <a>default
sources</a>.
If <code>'unsafe-inline'</code> is <strong>not</strong> in the
list of <a>allowed script sources</a>, or if at least one
<code><a>nonce-source</a></code> or <code><a>hash-source</a></code> is
present in the list of <a>allowed script sources</a>:
<ul>
<li>Whenever the user agent would execute an inline script from a
<code><a element>script</a></code> element that lacks a <a>valid nonce</a>
<em>and</em> lacks a <a>valid hash</a> for the <a>allowed script
sources</a>, instead the user agent MUST NOT execute script, <em>and</em>
MUST <a>report a violation</a>.</li>
<li>Whenever the user agent would execute an inline script from an
inline event handler, instead the user agent MUST NOT execute script,
<em>and</em> MUST <a>report a violation</a>.</li>
<li>Whenever the user agent would execute script contained in a
<code>javascript</code> URL, instead the user agent MUST NOT execute
the script, <em>and</em> MUST <a>report a violation</a>.</li>
</ul>
If <code>'unsafe-eval'</code> is <strong>not</strong> in <a>allowed script
sources</a>:
<ul>
<li>Instead of evaluating their arguments, both operator
<code>eval</code> and function <code>eval</code> [[!ECMA-262]]
MUST throw an <code>EvalError</code> exception.</li>
<li>When called as a constructor, the function <code>Function</code>
[[!ECMA-262]] MUST throw an <code>EvalError</code> exception.</li>
<li>When called with a first argument that is not <a>callable</a> (a
string, for example), the
<code><a method for="WindowTimers">setTimeout()</a></code> function MUST
return zero without creating a timer.</li>
<li>When called with a first argument that is not <a>callable</a> (a
string, for example), the
<code><a method for="WindowTimers">setInterval()</a></code> function MUST
return zero without creating a timer.</li>
</ul>
Whenever the user agent <a>fetches</a> a URL (including when following
redirects) in the course of one of the following activities, if the URL does
not <a lt="match a source list">match</a> the <a>allowed script
sources</a> for the <a>protected resource</a>, the user agent MUST act as if
there was a fatal network error and no resource was obtained, <em>and</em>
<a>report a violation</a>:
<ul>
<li>Requesting a script while processing the <{script/src}> attribute of
a <{script}> element that lacks a <a>valid nonce</a> for the <a>allowed
script sources</a>.</li>
<li>Requesting a script while invoking the <code>importScripts</code>
method on a WorkerGlobalScope object. [[!WORKERS]]</li>
<li>Requesting an HTML component, such as
when processing the <code>href</code> attribute of a <code><a element>link</a></code>
element with a <code>rel</code> attribute containing the token
<code>import</code>. [[!HTML-IMPORTS]]</li>
<li>Requesting an Extensible Stylesheet Language Transformations
(XSLT) [[!XSLT]], such as when processing the
<code><?xml-stylesheet?></code> processing directive in an XML
document [[!XML11]], the <code><a element-attr>href</a></code> attributes
on <code><xsl:include></code> and <code><xsl:import></code>
elements.</li>
</ul>
<section class="informative">
<h4 id="script-src-nonce-usage">
Nonce usage for <code><a element>script</a></code> elements
</h4>
<em>This section is not normative.</em>
The <code><a>script-src</a></code> directive lets developers specify
exactly which script elements on a page were intentionally included
for execution. Ideally, developers would avoid inline script entirely
and whitelist scripts by URL. However, in some cases, removing inline
scripts can be difficult or impossible. For those cases, developers can
whitelist scripts using a randomly generated nonce.
Usage is straightforward. For <em>each</em> request, the server
generates a unique value at random, and includes it in the
<code>Content-Security-Policy</code> header:
<pre>
Content-Security-Policy: <a>default-src</a> 'self';
<a>script-src</a> 'self' https://example.com 'nonce-<em>$RANDOM</em>'
</pre>
This same value is then applied as a <code>nonce</code> attribute
to each <code><a element>script</a></code> element that ought to be
executed. For example, if the server generated the random value
<code>Nc3n83cnSAd3wc3Sasdfn939hc3</code>, the server would send the
following policy:
<pre>
Content-Security-Policy: <a>default-src</a> 'self';
<a>script-src</a> 'self' https://example.com 'nonce-Nc3n83cnSAd3wc3Sasdfn939hc3'
</pre>
Script elements can then execute either because their <{script/src}> URLs
are whitelisted or because they have a <a>valid nonce</a>:
<pre>
<script>
alert("Blocked because the policy doesn't have 'unsafe-inline'.")
</script>
<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
alert("Still blocked because nonce is wrong.")
</script>
<script nonce="Nc3n83cnSAd3wc3Sasdfn939hc3">
alert("Allowed because nonce is valid.")
</script>
<script src="https://example.com/allowed-because-of-src.js"></script>
<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa"
src="https://elsewhere.com/blocked-because-nonce-is-wrong.js"></script>
<script nonce="Nc3n83cnSAd3wc3Sasdfn939hc3"
src="https://elsewhere.com/allowed-because-nonce-is-valid.js"></script>
</pre>
Note that the nonce's value is <em>not</em> a hash or signature
that verifies the contents of the script resources. It's quite simply
a random string that informs the user agent which scripts were
intentionally included in the page.
Script elements with the proper nonce execute, regardless of
whether they're inline or external. Script elements without the
proper nonce don't execute unless their URLs are whitelisted.
Even if an attacker is able to inject markup into the protected
resource, the attack will be blocked by the attacker's inability
to guess the random value.
</section>
<section class="informative">
<h4 id="script-src-hash-usage">
Hash usage for <code><a element>script</a></code> elements
</h4>
<em>This section is not normative.</em>
The <code><a>script-src</a></code> directive lets developers whitelist a
particular inline script by specifying its hash as an allowed source
of script.
Usage is straightforward. The server computes the hash of a
particular script block's contents, and includes the base64 encoding
of that value in the <code>Content-Security-Policy</code> header:
<pre>
Content-Security-Policy: <a>default-src</a> 'self';
<a>script-src</a> 'self' https://example.com 'sha256-<var>base64 encoded hash</var>'
</pre>
Each inline script block's contents are hashed, and compared against
the whitelisted value. If there's a match, the script is executed. For
example, the SHA-256 digest of <code>alert('Hello, world.');</code> is
<code>qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=</code>.
<div class="example">
You can obtain the digest of a string on the command line simply
via the <code>openssl</code> program. For example:
<pre>
echo -n "alert('Hello, world.');" | openssl dgst -sha256 -binary | openssl enc -base64
</pre>
</div>
If the server sent the following header:
<pre>
Content-Security-Policy: <a>script-src</a> 'sha512-YWIzOWNiNzJjNDRlYzc4MTgwMDhmZDlkOWI0NTAyMjgyY2MyMWJlMWUyNjc1ODJlYWJhNjU5MGU4NmZmNGU3OAo='
</pre>
Then the following script tag would result in script execution:
<pre>
<script>alert('Hello, world.');</script>
</pre>
Whitespace is significant. The following scripts blocks would not hash to
the same value, and would therefore <em>not</em> execute:
<pre>
<script> alert('Hello, world.');</script>
<script>alert('Hello, world.'); </script>
<script> alert('Hello, world.'); </script>
<script>
alert('Hello, world.');
</script>
</pre>
Note also that the hash applies <em>only</em> to inline script. An
externalized script containing the value
<code>alert('Hello, world.');</code> would <em>not</em> execute if its
origin was not whitelisted as a valid source of script.
</section>
</section>
<!--
██████ ████████ ██ ██ ██ ████████ ██████ ████████ ██████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ████ ██ ██ ██ ██ ██ ██
██████ ██ ██ ██ ██████ ███████ ██████ ████████ ██
██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██████ ██ ██ ████████ ████████ ██████ ██ ██ ██████
-->
<section>
<h3 id="directive-style-src"><code>style-src</code></h3>
The <code><dfn>style-src</dfn></code> directive restricts which styles the
user agent applies to the protected resource. The syntax for the name and
value of the directive are described by the following ABNF grammar:
<pre>
directive-name = "style-src"
directive-value = <a>source-list</a>
</pre>
The term <dfn>allowed style sources</dfn> refers to the result of
<a lt="parse a source list">parsing the <code>style-src</code>
directive's value as a source list</a> if the policy contains an
explicit <code>style-src</code>, or otherwise to the <a>default sources</a>.
If <code>'unsafe-inline'</code> is <strong>not</strong> in the
list of <a>allowed style sources</a>, or if at least one
<code><a>nonce-source</a></code> or <code><a>hash-source</a></code>
is present in the list of <a>allowed style sources</a>:
<ul>
<li>Whenever the user agent would apply style from a
<code><a element>style</a></code> element that lacks a
<a>valid nonce</a> <em>and</em> lacks a <a>valid hash</a> for the
<a>allowed style sources</a>, instead the user agent <code>MUST</code>
ignore the style, <em>and</em> MUST <a>report a violation</a>.</li>
<li>Whenever the user agent would apply style from a
<code><a element>style</a></code> attribute, instead the user agent
<code>MUST</code> ignore the style, <em>and</em> MUST <a>report a
violation</a>.</li>
</ul>
Note: These restrictions on inline do not prevent the user agent
from applying style from an external stylesheet (e.g., found via
<code><link rel="stylesheet" ...></code>).
If <code>'unsafe-eval'</code> is <strong>not</strong> in <a>allowed style
sources</a>, then:
<ul>
<li>Whenever the user agent would invoke the Cascading Style Sheets
Object Model algorithms
<a spec="CSSOM">insert a CSS rule</a>, <a spec="CSSOM">parse a CSS rule</a>,
<a spec="CSSOM">parse a CSS declaration block</a>, or
<a spec="CSSOM">parse a group of selectors</a>
instead the user agent MUST throw a <a spec="HTML5">SecurityError</a>
exception <em>and</em> terminate the algorithm. This would include,
for example, all invocations of CSSOM's various <code>cssText</code>
setters and <code>insertRule</code> methods. [[!CSSOM]] [[!HTML5]]</li>
</ul>
Whenever the user agent <a>fetches</a> a URL in the course of one of the
following activities, if the URL does not
<a lt="match a source list">match</a> the <a>allowed style sources</a>
for the <a>protected resource</a>, the user agent MUST act as if there was
a fatal network error and no resource was obtained, <em>and</em> <a>report
a violation</a>:
<ul>
<li>
Requesting an external stylesheet when processing the
<a element-attr for="link">href</a> of a <a element>link</a> element
whose <a element-attr for="link">rel</a> attribute contains the token
<code><a lt="link type stylesheet">stylesheet</a></code>.
</li>
<li>
Requesting an external stylesheet when processing the <<@import>>
directive.
</li>
<li>
Requesting an external stylesheet when processing a <code>Link</code>
HTTP response header field. [[!RFC5988]]
Note: As this stylesheet might be prefetched before a {{Document}}
actually exists, user agents will need to carefully consider how to
instantiate a meaningful <a>policy</a> against which to compare this
request. See [[#complications]] for more detail.
</li>
</ul>
Note: The <code>style-src</code> directive does not restrict the
use of XSLT. XSLT is restricted by the <code><a>script-src</a></code>
directive because the security consequences of including an untrusted
XSLT stylesheet are similar to those incurred by including an
untrusted script.
<section class="informative">
<h4 id="style-src-nonce-usage">
Nonce usage for <code><a element>style</a></code> elements
</h4>
<em>This section is not normative.</em>
See the <a href="#script-src-nonce-usage"><code>script-src</code>
nonce usage information</a> for detail; the application of nonces
to <code><a element>style</a></code> elements is similar enough to avoid
repetition here.
</section>
<section class="informative">
<h4 id="style-src-hash-usage">
Hash usage for <code><a element>style</a></code> elements
</h4>
<em>This section is not normative.</em>
See the <a href="#script-src-hash-usage"><code>script-src</code>
hash usage information</a> for detail; the application of hashes
to <code><a element>style</a></code> elements is similar enough to avoid
repetition here.
</section>
</section>
</section>
<!--
████████ ██ ██ ███ ██ ██ ████████ ██ ████████ ██████
██ ██ ██ ██ ██ ███ ███ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ████ ████ ██ ██ ██ ██ ██
██████ ███ ██ ██ ██ ███ ██ ████████ ██ ██████ ██████
██ ██ ██ █████████ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
████████ ██ ██ ██ ██ ██ ██ ██ ████████ ████████ ██████
-->
<section>
<h2 id="examples">Examples</h2>
<section class="informative">
<h3 id="example-policies">Sample Policy Definitions</h3>
This section provides some sample use cases and supporting <a>policies</a>.
<div class="example">
A server wishes to load resources only from its own origin:
<pre>Content-Security-Policy: <a>default-src</a> 'self'</pre>
</div>
<div class="example">
An auction site wishes to load images from any URL, plugin content from a
list of trusted media providers (including a content distribution network),
and scripts only from a server under its control hosting sanitized
ECMAScript:
<pre>
Content-Security-Policy:
<a>default-src</a> 'self'; img-src *;
<a>object-src</a> media1.example.com media2.example.com *.cdn.example.com;
<a>script-src</a> trustedscripts.example.com
</pre>
</div>
<div class="example">
An online banking site wishes to ensure that all of the content in its pages
is loaded over TLS to prevent attackers from eavesdropping on insecure
content requests:
<pre>Content-Security-Policy: <a>default-src</a> https: 'unsafe-inline' 'unsafe-eval'</pre>
This policy allows inline content (such as inline
<code><a element>script</a></code> elements), use of <code>eval</code>,
and loading resources over <code>https</code>. Note: This policy does
not provide any protection from cross-site scripting vulnerabilities.
</div>
<div class="example">
A website that relies on inline <code><a element>script</a></code> elements
wishes to ensure that script is only executed from its own origin, and those
elements it intentionally inserted inline:
<pre>Content-Security-Policy: <a>script-src</a> 'self' 'nonce-<em>$RANDOM</em>';</pre>
The inline <code><a element>script</a></code> elements would then only
execute if they contained a matching
<code><a element-attr for="script">nonce</a></code> attribute:
<pre><script nonce="<em>$RANDOM</em>">...</script></pre>
</div>
</section>
<section class="informative">
<h3 id="example-violation-report">Sample Violation Report</h3>
This section contains an example violation report the user agent
might sent to a server when the protected resource violations a sample
policy.
In the following example, the user agent rendered a representation
of the resource <code>http://example.org/page.html</code> with the
following policy:
<pre><a>default-src</a> 'self'; <a>report-uri</a> http://example.org/csp-report.cgi</pre>
The protected resource loaded an image from
<code>http://evil.example.com/image.png</code>, violating the
policy.
<pre>
{
"csp-report": {
"document-uri": "http://example.org/page.html",
"referrer": "http://evil.example.com/haxor.html",
"blocked-uri": "http://evil.example.com/image.png",
"violated-directive": "default-src 'self'",
"effective-directive": "img-src",
"original-policy": "default-src 'self'; report-uri http://example.org/csp-report.cgi"
}
}
</pre>
</section>
</section>
<!--
██████ ████████ ██████ ██ ██ ████████ ████ ████████ ██ ██ ██████ ███████ ██ ██ ██████ ████ ████████ ████████ ████████ ███ ████████ ████ ███████ ██ ██ ██████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ████ ██ ██ ██ ████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ████ ██ ██
██████ ██████ ██ ██ ██ ████████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██████ ██ ██ ██ ██████ ████████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ████ ██ ██ ██ ██ ██ ██ ██ █████████ ██ ██ ██ ██ ██ ████ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██
██████ ████████ ██████ ███████ ██ ██ ████ ██ ██ ██████ ███████ ██ ██ ██████ ████ ████████ ████████ ██ ██ ██ ██ ██ ████ ███████ ██ ██ ██████
-->
<section>
<h2 id="security-considerations">Security Considerations</h2>
<section>
<h3 id="security-css-parsing">Cascading Style Sheet (CSS) Parsing</h3>
The <code><a>style-src</a></code> directive restricts the locations from
which the protected resource can load styles. However, if the user agent uses a
lax CSS parsing algorithm, an attacker might be able to trick the user
agent into accepting malicious "stylesheets" hosted by an otherwise
trustworthy origin.
These attacks are similar to the <a
href="http://scarybeastsecurity.blogspot.com/2009/12/generic-cross-browser-cross-domain.html">CSS
cross-origin data leakage</a> attack described by Chris Evans in 2009.
User agents SHOULD defend against both attacks using the same
mechanism: stricter CSS parsing rules for style sheets with improper
MIME types.
</section>
<section>
<h3 id="security-redirects">Redirect Information Leakage</h3>
The violation reporting mechanism in this document has been
designed to mitigate the risk that a malicious web site could use
violation reports to probe the behavior of other servers. For example,
consider a malicious web site that white lists <code>https://example.com</code>
as a source of images. If the malicious site attempts to load
<code>https://example.com/login</code> as an image, and the
<code>example.com</code> server redirects to an identity provider (e.g.,
<code>identityprovider.example.net</code>), CSP will block the request.
If violation reports contained the full blocked URL, the violation
report might contain sensitive information contained in the redirected URL,
such as session identifiers or purported identities. For this reason, the
user agent includes only the origin of the blocked URL.
The mitigations are not complete, however: redirects which are blocked will
produce side-effects which may be visible to JavaScript (via
<code>img.naturalHeight</code>, for instance). An earlier version of this
specification defined a
<a href="http://www.w3.org/TR/2015/CR-CSP2-20150721/#csp-request-header"><code>CSP</code>
request header</a> which servers could use (in conjunction with the
<code>referer</code> and <code>origin</code> headers) to determine whether
or not it was completely safe to redirect a user. This header caused some
issues with CORS processing (tracked in
<a href="https://github.com/whatwg/fetch/issues/52">whatwg/fetch#52</a>),
and has been punted to the next version of this document.
</section>
</section>
<!--
████ ██ ██ ████████ ██ ████████ ██ ██ ████████ ██ ██ ████████ ███ ████████ ████ ███████ ██ ██ ██████ ███████ ██ ██ ██████ ████ ████████ ████████ ████████ ███ ████████ ████ ███████ ██ ██ ██████
██ ███ ███ ██ ██ ██ ██ ███ ███ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██
██ ████ ████ ██ ██ ██ ██ ████ ████ ██ ████ ██ ██ ██ ██ ██ ██ ██ ██ ████ ██ ██ ██ ██ ████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ████ ██ ██
██ ██ ███ ██ ████████ ██ ██████ ██ ███ ██ ██████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██████ ██ ██ ██ ██████ ████████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ████ ██ █████████ ██ ██ ██ ██ ██ ████ ██ ██ ██ ██ ████ ██ ██ ██ ██ ██ ██ ██ █████████ ██ ██ ██ ██ ██ ████ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██
████ ██ ██ ██ ████████ ████████ ██ ██ ████████ ██ ██ ██ ██ ██ ██ ████ ███████ ██ ██ ██████ ███████ ██ ██ ██████ ████ ████████ ████████ ██ ██ ██ ██ ██ ████ ███████ ██ ██ ██████
-->
<section>
<h2 id="implementation-considerations">Implementation Considerations</h2>
The <code><a>Content-Security-Policy</a></code> header is an end-to-end
header. It is processed and enforced at the client and, therefore,
SHOULD NOT be modified or removed by proxies or other intermediaries not
in the same administrative domain as the resource.
The originating administrative domain for a resource might wish to
apply a <code><a>Content-Security-Policy</a></code> header outside of the
immediate context of an application. For example, a large organization
might have many resources and applications managed by different
individuals or teams but all subject to a uniform organizational
standard. In such situations, a <code><a>Content-Security-Policy</a></code>
header might be added or combined with an existing one at a network-edge
security gateway device or web application firewall. To enforce multiple
policies, the administrator SHOULD combine the policy into a single header.
An administrator might wish to use different combination algorithms
depending on his or her intended semantics.
One sensible policy combination algorithm is to start by allowing a
default set of sources and then letting individual upstream resource
owners expand the set of allowed sources by including additional origins.
In this approach, the resultant policy is the union of all allowed
origins in the input policies.
Another sensible policy combination algorithm is to intersect the
given policies. This approach enforces that content comes from a certain
whitelist of origins, for example, preventing developers from including
third-party scripts or content in violation of organizational standards
and practices. In this approach, the combination algorithm forms the
combined policy by removing disallowed hosts from the policies supplied
by upstream resource owners.
Interactions between the <code><a>default-src</a></code> and other directives
SHOULD be given special consideration when combining policies. If none
of the policies contains a <code><a>default-src</a></code> directive, adding new
src directives results in a more restrictive policy. However, if one or
more of the input policies contain a <code><a>default-src</a></code> directive,
adding new src directives might result in a less restrictive policy, for
example, if the more specific directive contains a more permissive set of
allowed origins.
Using a more restrictive policy than the input policy authored by the
resource owner might prevent the resource from rendering or operating as
intended.
Note: Migration to <code>HTTPS</code> from <code>HTTP</code>
may require updates to the policy in order to keep things running as
before. Source expressions like <code>http://example.com</code> do
<em>not</em> match <code>HTTPS</code> resources. For example,
administrators SHOULD carefully examine existing policies before rolling
out <a href="https://tools.ietf.org/html/rfc6797">HTTP Strict Transport Security</a>
headers for an application. [[RFC6797]]
<div class="note">
Server administrators MAY wish to send multiple policies if different
reporting options are desired for subsets of an overall policy. For instance,
the following headers:
<pre>
Content-Security-Policy: <a>frame-ancestors</a> https://example.com/
Content-Security-Policy: <a>default-src</a> https:; report-uri https://example.com/
</pre>
would send violation reports for <code>http</code> resources, but would not
send violation reports for <code><a>frame-ancestors</a></code> violations.
Note also that combining them via '<code>,</code>' into the single header
<pre>
Content-Security-Policy: <a>frame-ancestors</a> https://example.com/, <a>default-src</a> https:; report-uri https://example.com/
</pre>
would have the same effect, as the comma splits the header during parsing.
</div>
<h3 id="complications">Processing Complications</h3>
Many user agents implement some form of optimistic resource fetching algorithm
to speed up page loads. In implementing these features, user agents MUST
ensure that these optimizations do not alter the behavior of the page's
security policy.
Here, we'll note a few potential complications that could cause bugs in
implementations:
<ol>
<li>
The <a>frame-ancestor</a> directive MUST take effect before a document is
loaded into a <a>nested browsing context</a>, and certainly before script
is potentially executed. One way to approach this constraint is to perform
the ancestor check defined in [[#directive-frame-ancestors]] while parsing
the document's headers. This might mean that no document object is
available at all, which can complicate checks against <code>'self'</code>,
and <a>scheme</a>- or <a>port</a>-relative source expressions.
</li>
<li>
Likewise, the <code>Link</code> HTTP response header could generate
requests for stylesheet resources before a document is available. User
agents MUST ensure that any policy contained in the response headers is
parsed and effective <em>before</em> these requests are generated. For
example, a response returning the following headers:
<pre>
Content-Security-Policy: style-src 'none'
Link: <awesome.css>; rel=stylesheet
</pre>
MUST have the same behavior as a response returning the following headers:
<pre>
Link: <awesome.css>; rel=stylesheet
Content-Security-Policy: style-src 'none'
</pre>
namely, both must block requests for the stylesheet. To meet this
requirement user agents MUST wait until all headers have been processed
before beginning to prefetch resources.
</li>
</ol>
</section>
<!--
████ ███ ██ ██ ███
██ ██ ██ ███ ██ ██ ██
██ ██ ██ ████ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██
██ █████████ ██ ████ █████████
██ ██ ██ ██ ███ ██ ██
████ ██ ██ ██ ██ ██ ██
-->
<section>
<h2 id="iana-considerations">IANA Considerations</h2>
The permanent message header field registry should be updated
with the following registrations: [[!RFC3864]]
<section>
<h3 id="iana-content-security-policy">Content-Security-Policy</h3>
<dl>
<dt>Header field name</dt>
<dd>Content-Security-Policy</dd>
<dt>Applicable protocol</dt>
<dd>http</dd>
<dt>Status</dt>
<dd>standard</dd>
<dt>Author/Change controller</dt>
<dd>W3C</dd>
<dt>Specification document</dt>
<dd>This specification (See <code><a>Content-Security-Policy</a></code>
Header Field)</dd>
</dl>
</section>
<section>
<h3 id="iana-content-security-policy-report-only">Content-Security-Policy-Report-Only</h3>
<dl>
<dt>Header field name</dt>
<dd>Content-Security-Policy-Report-Only</dd>
<dt>Applicable protocol</dt>
<dd>http</dd>
<dt>Status</dt>
<dd>standard</dd>
<dt>Author/Change controller</dt>
<dd>W3C</dd>
<dt>Specification document</dt>
<dd>This specification (See
<code><a>Content-Security-Policy-Report-Only</a></code> Header Field)</dd>
</dl>
</section>
</section>
<section>
<h2 id="acknowledgements">Acknowledgements</h2>
In addition to the documents in the W3C Web Application Security working
group, the work on this document is also informed by the work of the
<a href="https://tools.ietf.org/wg/websec/">IETF websec working group</a>,
particularly that working group's requirements document:
<a href="https://tools.ietf.org/id/draft-hodges-websec-framework-reqs">draft-hodges-websec-framework-reqs</a>.
A portion of the <code><a>frame-ancestors</a></code> directive was
originally developed as <code>X-Frame-Options</code>. [[RFC7034]]
Brian Smith, Neil Matatall, Anne van Kesteren, and Sigbjørn Vik provided
particularly insightful feedback to keep this specification sane.
</section>
================================================
FILE: 2/published/2015-02-CR.html
================================================
<!doctype html>
<html lang="en">
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<title>Content Security Policy Level 2</title>
<link href="default.css" rel="stylesheet" type="text/css">
<link href="https://www.w3.org/StyleSheets/TR/W3C-CR" rel="stylesheet" type="text/css">
<meta content="Bikeshed 1.0.0" name="generator">
<style>
table {
text-align: left;
margin: 20px;
width: 100%;
border-collapse: collapse;
}
tbody tr:nth-child(odd) {
background-color: #EEE;
}
th {
border-bottom: 1px solid #999;
padding: 0.5em;
}
td:first-child {
width: 30%;
padding-right: 1em;
}
td {
vertical-align: top;
padding: 0.5em;
}
tbody th {
border: 0;
background-color: #FFF;
}
tr.section {
border-top: 1px solid #999;
vertical-align: top;
}
</style>
</head>
<body class="h-entry">
<div class="head">
<p data-fill-with="logo"><a class="logo" href="http://www.w3.org/">
<img alt="W3C" height="48" src="https://www.w3.org/Icons/w3c_home" width="72">
</a>
</p>
<h1 class="p-name no-ref" id="title">Content Security Policy Level 2</h1>
<h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">W3C Candidate Recommendation,
<time class="dt-updated" datetime="2015-02-19">19 February 2015</time></span></h2>
<div data-fill-with="spec-metadata">
<dl>
<dt>This version:
<dd><a class="u-url" href="http://www.w3.org/TR/2015/CR-CSP2-20150219/">http://www.w3.org/TR/2015/CR-CSP2-20150219/</a>
<dt>Latest version:
<dd><a href="http://www.w3.org/TR/CSP2/">http://www.w3.org/TR/CSP2/</a>
<dt>Editor's Draft:
<dd><a href="https://w3c.github.io/webappsec/specs/CSP2/">https://w3c.github.io/webappsec/specs/CSP2/</a>
<dt>Previous Versions:
<dd><a href="http://www.w3.org/TR/2014/WD-CSP2-20140703/" rel="previous">http://www.w3.org/TR/2014/WD-CSP2-20140703/</a>
<dd><a href="http://www.w3.org/TR/2014/WD-CSP11-20140211/" rel="previous">http://www.w3.org/TR/2014/WD-CSP11-20140211/</a>
<dd><a href="http://www.w3.org/TR/2012/CR-CSP-20121115/" rel="previous">http://www.w3.org/TR/2012/CR-CSP-20121115/</a>
<dt>Feedback:
<dd><span><a href="mailto:public-webappsec@w3.org?subject=%5BCSP2%5D%20feedback">public-webappsec@w3.org</a> with subject line “<kbd>[CSP2] <var>… message topic …</var></kbd>” (<a href="http://lists.w3.org/Archives/Public/public-webappsec/" rel="discussion">archives</a>)</span>
<dt class="editor">Editors:
<dd class="editor p-author h-card vcard" data-editor-id="56384"><a class="p-name fn u-email email" href="mailto:mkwst@google.com">Mike West</a> (<span class="p-org org">Google Inc.</span>)
<dd class="editor p-author h-card vcard" data-editor-id="39502"><a class="p-name fn u-email email" href="mailto:w3c@adambarth.com">Adam Barth</a> (<span class="p-org org">Google Inc.</span>)
<dd class="editor p-author h-card vcard" data-editor-id="41156"><a class="p-name fn u-email email" href="mailto:dveditz@mozilla.com">Dan Veditz</a> (<span class="p-org org">Mozilla Corporation</span>)
<dt>Former Editors:
<dd>
<dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:brandon@hackmill.com">Brandon Sterne</a> (<span class="p-org org">formerly of Mozilla Corporation</span>)
</dl>
</div>
<div data-fill-with="warning"></div>
<p class="copyright" data-fill-with="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2015 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>). W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.
</p>
<hr title="Separator for header">
</div>
<h2 class="no-num no-toc no-ref heading settled" id="abstract"><span class="content">Abstract</span></h2>
<div class="p-summary" data-fill-with="abstract">
<p>This document defines a policy language used to declare a set of content restrictions for a web resource, and a mechanism for transmitting the policy from a server to a client where the policy is enforced.</p>
</div>
<h2 class="no-num no-toc no-ref heading settled" id="status"><span class="content">Status of this document</span></h2>
<div data-fill-with="status">
<p>
<em>This section describes the status of this document at the time of
its publication. Other documents may supersede this document. A list of
current W3C publications and the latest revision of this technical report
can be found in the <a href="http://www.w3.org/TR/">W3C technical reports
index at http://www.w3.org/TR/.</a></em>
</p>
<p>
This document was published by the
<a href="http://www.w3.org/2011/webappsec/">Web Application Security Working Group</a>
as a Candidate Recommendation. This document is intended to become a W3C Recommendation.
This document will remain a Candidate Recommendation at least until 1 July 2015 in order
to ensure the opportunity for wide review.
</p>
<p>
The (<a href="http://lists.w3.org/Archives/Public/public-webappsec/">archived</a>) public mailing list
<a href="mailto:public-webappsec@w3.org?Subject=%5BCSP2%5D%20PUT%20SUBJECT%20HERE">public-webappsec@w3.org</a>
(see <a href="http://www.w3.org/Mail/Request">instructions</a>)
is preferred for discussion of this specification.
When sending e-mail,
please put the text “CSP2” in the subject,
preferably like this:
“[CSP2] <em>…summary of comment…</em>”
</p>
<p>
Publication as a Candidate Recommendation does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite this
document as other than work in progress.
</p>
<p>
The entrance criteria for this document to enter the Proposed Recommendation stage
is to have a minimum of two independent and interoperable user agents that
implementation all the features of this specification, which will be determined by
passing the user agent tests defined in the test suite developed by the Working
Group. The Working Group will prepare an implementation report to track progress.
</p>
<p>
This document was produced by a group operating under
the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>.
W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/49309/status" rel="disclosure">public list of any patent disclosures</a>
made in connection with the deliverables of the group;
that page also includes instructions for disclosing a patent.
An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a>
must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.
</p>
<p>
This document is governed by the <a href="http://www.w3.org/2014/Process-20140801/" id="w3c_process_revision">1 August 2014 W3C Process Document</a>.
</p></div>
<div data-fill-with="at-risk">
<p>The following features are at-risk, and may be dropped during the CR period:
</p>
<ul>
<li><a href="#csp-request-header">§3.4 The CSP HTTP Request Header</a>
<li><a href="#directive-child-src">§7.2 child-src</a>
</ul></div>
<h2 class="no-num no-toc no-ref heading settled" id="contents"><span class="content">Table of Contents</span></h2>
<div data-fill-with="table-of-contents" role="navigation">
<ul class="toc" role="directory">
<li><a href="#intro"><span class="secno">1</span> <span class="content">Introduction</span></a>
<ul class="toc">
<li><a href="#changes-from-level-1"><span class="secno">1.1</span> <span class="content">Changes from Level 1</span></a>
</ul>
<li><a href="#key-concepts"><span class="secno">2</span> <span class="content">Key Concepts and Terminology</span></a>
<ul class="toc">
<li><a href="#terms-defined-here"><span class="secno">2.1</span> <span class="content">Terms defined by this specification</span></a>
<li><a href="#terms-defined-by-reference"><span class="secno">2.2</span> <span class="content">Terms defined by reference</span></a>
<li><a href="#html-concepts"><span class="secno">2.3</span> <span class="content">Relevant Concepts from HTML</span></a>
<li><a href="#grammar"><span class="secno">2.4</span> <span class="content">Grammatical Concepts</span></a>
</ul>
<li><a href="#policy-delivery"><span class="secno">3</span> <span class="content">Policy Delivery</span></a>
<ul class="toc">
<li><a href="#content-security-policy-header-field"><span class="secno">3.1</span> <span class="content">
<code>Content-Security-Policy</code> Header Field
</span></a>
<li><a href="#content-security-policy-report-only-header-field"><span class="secno">3.2</span> <span class="content">
<code>Content-Security-Policy-Report-Only</code> Header Field
</span></a>
<li><a href="#delivery-html-meta-element"><span class="secno">3.3</span> <span class="content">
HTML <code><span data-lt="meta">meta</span></code> Element
</span></a>
<li><a href="#csp-request-header"><span class="secno">3.4</span> <span class="content">The <code>CSP</code> HTTP Request Header</span></a>
<li><a href="#enforcing-multiple-policies"><span class="secno">3.5</span> <span class="content">Enforcing multiple policies.</span></a>
<li><a href="#which-policy-applies"><span class="secno">3.6</span> <span class="content">Policy applicability</span></a>
</ul>
<li><a href="#syntax-and-algorithms"><span class="secno">4</span> <span class="content">Syntax and Algorithms</span></a>
<ul class="toc">
<li><a href="#policy-syntax"><span class="secno">4.1</span> <span class="content">Policy Syntax</span></a>
<ul class="toc">
<li><a href="#policy-parsing"><span class="secno">4.1.1</span> <span class="content">Parsing Policies</span></a>
</ul>
<li><a href="#source-list-syntax"><span class="secno">4.2</span> <span class="content">Source List Syntax</span></a>
<ul class="toc">
<li><a href="#source-list-parsing"><span class="secno">4.2.1</span> <span class="content">Parsing Source Lists</span></a>
<li><a href="#match-source-expression"><span class="secno">4.2.2</span> <span class="content">Matching Source Expressions</span></a>
<ul class="toc">
<li><a href="#source-list-guid-matching"><span class="secno">4.2.2.1</span> <span class="content">
Security Considerations for GUID URL schemes
</span></a>
<li><a href="#source-list-path-patching"><span class="secno">4.2.2.2</span> <span class="content">Path Matching</span></a>
<li><a href="#source-list-paths-and-redirects"><span class="secno">4.2.2.3</span> <span class="content">Paths and Redirects</span></a>
</ul>
<li><a href="#script-src-the-nonce-attribute"><span class="secno">4.2.3</span> <span class="content">
The <code>nonce</code> attribute
</span></a>
<li><a href="#source-list-valid-nonces"><span class="secno">4.2.4</span> <span class="content">Valid Nonces</span></a>
<li><a href="#source-list-valid-hashes"><span class="secno">4.2.5</span> <span class="content">Valid Hashes</span></a>
</ul>
<li><a href="#media-type-list-syntax"><span class="secno">4.3</span> <span class="content">Media Type List Syntax</span></a>
<ul class="toc">
<li><a href="#media-type-list-parsing"><span class="secno">4.3.1</span> <span class="content">Parsing</span></a>
<li><a href="#media-type-list-matching"><span class="secno">4.3.2</span> <span class="content">Matching</span></a>
</ul>
<li><a href="#violation-reports"><span class="secno">4.4</span> <span class="content">Reporting</span></a>
</ul>
<li><a href="#processing-model"><span class="secno">5</span> <span class="content">Processing Model</span></a>
<ul class="toc">
<li><a href="#processing-model-workers"><span class="secno">5.1</span> <span class="content">Workers</span></a>
<li><a href="#processing-model-iframe-srcdoc"><span class="secno">5.2</span> <span class="content"><code>srcdoc</code> IFrames</span></a>
</ul>
<li><a href="#script-interfaces"><span class="secno">6</span> <span class="content">Script Interfaces</span></a>
<ul class="toc">
<li><a href="#securitypolicyviolationevent-interface"><span class="secno">6.1</span> <span class="content">
<code>SecurityPolicyViolationEvent</code> Interface
</span></a>
<li><a href="#securitypolicyviolationeventinit-interface"><span class="secno">6.2</span> <span class="content">
<code>SecurityPolicyViolationEventInit</code> Interface
</span></a>
<li><a href="#firing-securitypolicyviolationevent-events"><span class="secno">6.3</span> <span class="content">Firing Violation Events</span></a>
</ul>
<li><a href="#directives"><span class="secno">7</span> <span class="content">Directives</span></a>
<ul class="toc">
<li><a href="#directive-base-uri"><span class="secno">7.1</span> <span class="content"><code>base-uri</code></span></a>
<li><a href="#directive-child-src"><span class="secno">7.2</span> <span class="content"><code>child-src</code></span></a>
<ul class="toc">
<li><a href="#directive-child-src-nested"><span class="secno">7.2.1</span> <span class="content">Nested Browsing Contexts</span></a>
<li><a href="#directive-child-src-workers"><span class="secno">7.2.2</span> <span class="content">Workers</span></a>
</ul>
<li><a href="#directive-connect-src"><span class="secno">7.3</span> <span class="content"><code>connect-src</code></span></a>
<ul class="toc">
<li><a href="#connect-src-usage"><span class="secno">7.3.1</span> <span class="content">Usage</span></a>
</ul>
<li><a href="#directive-default-src"><span class="secno">7.4</span> <span class="content"><code>default-src</code></span></a>
<ul class="toc">
<li><a href="#default-src-usage"><span class="secno">7.4.1</span> <span class="content">Usage</span></a>
</ul>
<li><a href="#directive-font-src"><span class="secno">7.5</span> <span class="content"><code>font-src</code></span></a>
<li><a href="#directive-form-action"><span class="secno">7.6</span> <span class="content"><code>form-action</code></span></a>
<li><a href="#directive-frame-ancestors"><span class="secno">7.7</span> <span class="content"><code>frame-ancestors</code></span></a>
<ul class="toc">
<li><a href="#frame-ancestors-and-frame-options"><span class="secno">7.7.1</span> <span class="content">
Relation to <code>X-Frame-Options</code>
</span></a>
<li><a href="#frame-ancestors-multiple-source-values"><span class="secno">7.7.2</span> <span class="content">Multiple Host Source Values</span></a>
</ul>
<li><a href="#directive-frame-src"><span class="secno">7.8</span> <span class="content"><code>frame-src</code></span></a>
<li><a href="#directive-img-src"><span class="secno">7.9</span> <span class="content"><code>img-src</code></span></a>
<li><a href="#directive-media-src"><span class="secno">7.10</span> <span class="content"><code>media-src</code></span></a>
<li><a href="#directive-object-src"><span class="secno">7.11</span> <span class="content"><code>object-src</code></span></a>
<li><a href="#directive-plugin-types"><span class="secno">7.12</span> <span class="content"><code>plugin-types</code></span></a>
<ul class="toc">
<li><a href="#plugin-types-usage"><span class="secno">7.12.1</span> <span class="content">Usage</span></a>
<li><a href="#plugin-types-predeclaration"><span class="secno">7.12.2</span> <span class="content">
Predeclaration of expected media types
</span></a>
</ul>
<li><a href="#directive-report-uri"><span class="secno">7.13</span> <span class="content"><code>report-uri</code></span></a>
<li><a href="#directive-sandbox"><span class="secno">7.14</span> <span class="content"><code>sandbox</code></span></a>
<ul class="toc">
<li><a href="#sandboxing-and-workers"><span class="secno">7.14.1</span> <span class="content">Sandboxing and Workers</span></a>
<li><a href="#sandbox-usage"><span class="secno">7.14.2</span> <span class="content">Usage</span></a>
</ul>
<li><a href="#directive-script-src"><span class="secno">7.15</span> <span class="content"><code>script-src</code></span></a>
<ul class="toc">
<li><a href="#script-src-nonce-usage"><span class="secno">7.15.1</span> <span class="content">
Nonce usage for <code><span data-lt="script">script</span></code> elements
</span></a>
<li><a href="#script-src-hash-usage"><span class="secno">7.15.2</span> <span class="content">
Hash usage for <code><span data-lt="script">script</span></code> elements
</span></a>
</ul>
<li><a href="#directive-style-src"><span class="secno">7.16</span> <span class="content"><code>style-src</code></span></a>
<ul class="toc">
<li><a href="#style-src-nonce-usage"><span class="secno">7.16.1</span> <span class="content">
Nonce usage for <code><span data-lt="style">style</span></code> elements
</span></a>
<li><a href="#style-src-hash-usage"><span class="secno">7.16.2</span> <span class="content">
Hash usage for <code><span data-lt="style">style</span></code> elements
</span></a>
</ul>
</ul>
<li><a href="#examples"><span class="secno">8</span> <span class="content">Examples</span></a>
<ul class="toc">
<li><a href="#example-policies"><span class="secno">8.1</span> <span class="content">Sample Policy Definitions</span></a>
<li><a href="#example-violation-report"><span class="secno">8.2</span> <span class="content">Sample Violation Report</span></a>
</ul>
<li><a href="#security-considerations"><span class="secno">9</span> <span class="content">Security Considerations</span></a>
<ul class="toc">
<li><a href="#security-css-parsing"><span class="secno">9.1</span> <span class="content">Cascading Style Sheet (CSS) Parsing</span></a>
<li><a href="#security-violation-reports"><span class="secno">9.2</span> <span class="content">Violation Reports</span></a>
</ul>
<li><a href="#implementation-considerations"><span class="secno">10</span> <span class="content">Implementation Considerations</span></a>
<ul class="toc">
<li><a href="#complications"><span class="secno">10.1</span> <span class="content">Processing Complications</span></a>
</ul>
<li><a href="#iana-considerations"><span class="secno">11</span> <span class="content">IANA Considerations</span></a>
<ul class="toc">
<li><a href="#iana-content-security-policy"><span class="secno">11.1</span> <span class="content">Content-Security-Policy</span></a>
<li><a href="#iana-content-security-policy-report-only"><span class="secno">11.2</span> <span class="content">Content-Security-Policy-Report-Only</span></a>
<li><a href="#iana-csp"><span class="secno">11.3</span> <span class="content">CSP</span></a>
</ul>
<li><a href="#acknowledgements"><span class="secno">12</span> <span class="content">Acknowledgements</span></a>
<li><a href="#conformance"><span class="secno"></span> <span class="content">Conformance</span></a>
<ul class="toc">
<li><a href="#conventions"><span class="secno"></span> <span class="content">Document conventions</span></a>
<li><a href="#conformant-algorithms"><span class="secno"></span> <span class="content">Conformant Algorithms</span></a>
<li><a href="#conformance-classes"><span class="secno"></span> <span class="content">Conformance Classes</span></a>
</ul>
<li><a href="#references"><span class="secno"></span> <span class="content">References</span></a>
<ul class="toc">
<li><a href="#normative"><span class="secno"></span> <span class="content">Normative References</span></a>
<li><a href="#informative"><span class="secno"></span> <span class="content">Informative References</span></a>
</ul>
<li><a href="#index"><span class="secno"></span> <span class="content">Index</span></a>
<li><a href="#idl-index"><span class="secno"></span> <span class="content">IDL Index</span></a>
</ul></div>
<main>
<section>
<h2 class="heading settled" data-level="1" id="intro"><span class="secno">1. </span><span class="content">Introduction</span><a class="self-link" href="#intro"></a></h2>
<p><em>This section is not normative.</em></p>
<p>This document defines Content Security Policy, a mechanism web applications
can use to mitigate a broad class of content injection vulnerabilities, such
as cross-site scripting (XSS). Content Security Policy is a declarative policy
that lets the authors (or server administrators) of a web application inform
the client about the sources from which the application expects to load
resources.</p>
<p>To mitigate XSS attacks, for example, a web application can declare that it
only expects to load script from specific, trusted sources. This declaration
allows the client to detect and block malicious scripts injected into the
application by an attacker.</p>
<p>Content Security Policy (CSP) is not intended as a first line of defense
against content injection vulnerabilities. Instead, CSP is best used as
defense-in-depth, to reduce the harm caused by content injection attacks. As
a first line of defense against content injection, server operators should
validate their input and encode their output.</p>
<p>There is often a non-trivial amount of work required to apply CSP to an
existing web application. To reap the greatest benefit, authors will need to
move all inline script and style out-of-line, for example into external
scripts, because the user agent cannot determine whether an inline script
was injected by an attacker.</p>
<p>To take advantage of CSP, a web application opts into using CSP by supplying a
<code>Content-Security-Policy</code> HTTP header. Such policies apply to the
current resource representation only. To supply a policy for an entire site,
the server needs to supply a policy with each resource representation.</p>
<h3 class="heading settled" data-level="1.1" id="changes-from-level-1"><span class="secno">1.1. </span><span class="content">Changes from Level 1</span><a class="self-link" href="#changes-from-level-1"></a></h3>
<p>This document describes an evolution of the
<a href="http://www.w3.org/TR/CSP/">Content Security Policy specification</a>.
Level 2 makes two breaking changes from Level 1, and adds support for a number
of new directives and capabilities which are summarized below:</p>
<ol>
<li>
The following changes are backwards incompatible with the majority of
user agent’s implementations of CSP 1:
<ol>
<li>
The path component of a source expression is now ignored if the
resource being loaded is the result of a redirect, as described in
<a href="#source-list-paths-and-redirects">§4.2.2.3 Paths and Redirects</a>.
<p class="note" role="note">Note: Paths are technically new in CSP2, but they were already
implemented in many user agents before this revision of CSP was
completed, so noting the change here seems reasonable.</p>
<li>
Redirects are blocked by default, and explicitly allowed with a new
<code>unsafe-redirect</code> expression.
<li>
A <a data-link-type="dfn" href="#protected-resource">protected resource</a>’s ability to load Workers is now controlled
via <a data-link-type="dfn" href="#child_src"><code>child-src</code></a> rather than
<a data-link-type="dfn" href="#script_src"><code>script-src</code></a>.
<li>
Workers now have their own policy, separate from the <a data-link-type="dfn" href="#protected-resource">protected
resource</a> which loaded them. This is described in
<a href="#processing-model-workers">§5.1 Workers</a>.
</ol>
<li>
The following directives are brand new in this revision:
<ol>
<li>
<a data-link-type="dfn" href="#base_uri"><code>base-uri</code></a> controls the <a data-link-type="dfn" href="#protected-resource">protected
resource</a>’s ability to specify the <a data-link-type="dfn" href="http://www.w3.org/TR/html5/infrastructure.html#document-base-url">document base
URL</a>.
<li>
<a data-link-type="dfn" href="#child_src"><code>child-src</code></a> deprecates and replaces
<a data-link-type="dfn" href="#frame_src"><code>frame-src</code></a>, controlling the <a data-link-type="dfn" href="#protected-resource">protected
resource</a>’s ability to embed frames, and to load Workers.
<li>
<a data-link-type="dfn" href="#form_action"><code>form-action</code></a> controls the <a data-link-type="dfn" href="#protected-resource">protected
resource</a>’s ability to submit forms.
<li>
<a data-link-type="dfn" href="#frame_ancestors"><code>frame-ancestors</code></a> controls the <a data-link-type="dfn" href="#protected-resource">protected
resource</a>’s ability be embedded in other documents. It is meant
to supplant the <code>X-Frame-Options</code> HTTP request header.
<li>
<a data-link-type="dfn" href="#plugin_types"><code>plugin-types</code></a> controls the <a data-link-type="dfn" href="#protected-resource">protected
resource</a>’s ability to load specific types of plugins.
</ol>
<li>
Individual inline scripts and stylesheets may be whitelisted via nonces
(as described in <a href="#source-list-valid-nonces">§4.2.4 Valid Nonces</a>) and hashes (as described
in <a href="#source-list-valid-hashes">§4.2.5 Valid Hashes</a>).
<li>
A <code>CSP</code> request header is now sent with relevant requests, as
described in <a href="#csp-request-header">§3.4 The CSP HTTP Request Header</a>.
<li>
A <code class="idl"><a data-link-type="idl" href="#securitypolicyviolationevent">SecurityPolicyViolationEvent</a></code> is fired upon violations, as described
in <a href="#firing-securitypolicyviolationevent-events">§6.3 Firing Violation Events</a>.
<li>
A number of new fields were added to violation reports (both those POSTED
via <a data-link-type="dfn" href="#report_uri"><code>report-uri</code></a>, and those handed to the DOM via
<code class="idl"><a data-link-type="idl" href="#securitypolicyviolationevent">SecurityPolicyViolationEvent</a></code> events. These include
<code class="idl"><a data-link-type="idl" href="#dom-securitypolicyviolationevent-effectivedirective">effectiveDirective</a></code>,
<code class="idl"><a data-link-type="idl" href="#dom-securitypolicyviolationevent-statuscode">statusCode</a></code>,
<code class="idl"><a data-link-type="idl" href="#dom-securitypolicyviolationevent-sourcefile">sourceFile</a></code>,
<code class="idl"><a data-link-type="idl" href="#dom-securitypolicyviolationevent-linenumber">lineNumber</a></code>, and
<code class="idl"><a data-link-type="idl" href="#dom-securitypolicyviolationevent-columnnumber">columnNumber</a></code>.
<li>
Certain flags present in the <code><a data-link-type="dfn" href="#sandbox">sandbox</a></code> directive now
affect Worker creation, as described in <a href="#sandboxing-and-workers">§7.14.1 Sandboxing and Workers</a>.
</ol>
</section>
<section>
<h2 class="heading settled" data-level="2" id="key-concepts"><span class="secno">2. </span><span class="content">Key Concepts and Terminology</span><a class="self-link" href="#key-concepts"></a></h2>
<h3 class="heading settled" data-level="2.1" id="terms-defined-here"><span class="secno">2.1. </span><span class="content">Terms defined by this specification</span><a class="self-link" href="#terms-defined-here"></a></h3>
<dl>
<dt>
<dfn data-dfn-type="dfn" data-export="" data-local-lt="policy" id="security-policy">security policy<a class="self-link" href="#security-policy"></a></dfn>
<dt>
<dfn data-dfn-type="dfn" data-export="" data-local-lt="directive" id="security-policy-directive">security policy directive<a class="self-link" href="#security-policy-directive"></a></dfn>
<dt>
<dfn data-dfn-type="dfn" data-export="" data-local-lt="directive name" id="security-policy-directive-name">security policy directive name<a class="self-link" href="#security-policy-directive-name"></a></dfn>
<dt>
<dfn data-dfn-type="dfn" data-export="" data-local-lt="directive value" id="security-policy-directive-value">security policy directive value<a class="self-link" href="#security-policy-directive-value"></a></dfn>
<dd>
A <strong>security policy</strong> refers to both a set of security
preferences for restrictions within which content can operate, and
to a fragment of text that codifies or transmits these preferences.
For example, the following string is a policy which restricts script
and object content:
<div class="example">
<code><a data-link-type="dfn" href="#script_src">script-src</a> 'self'; <a data-link-type="dfn" href="#object_src">object-src</a> 'none'</code>
</div>
<p>Security policies contain a set of <strong>security policy
directives</strong> (<code><a data-link-type="dfn" href="#script_src">script-src</a></code> and
<code><a data-link-type="dfn" href="#object_src">object-src</a></code> in the example above), each responsible
for declaring the restrictions for a particular resource type, or
manipulating a specific aspect of the policy’s restrictions. The list
of directives defined by this specification can be found in
<a href="#directives">§7 Directives</a>.</p>
<p>Each directives has a <strong>name</strong> and a <strong>value</strong>;
a detailed grammar can be found in <a href="#syntax-and-algorithms">§4 Syntax and Algorithms</a>.</p>
<dt>
<dfn data-dfn-type="dfn" data-export="" id="protected-resource">protected resource<a class="self-link" href="#protected-resource"></a></dfn>
<dd>
A <a data-link-type="dfn" href="#security-policy">security policy</a> is applied by a user agent to a specific
<a data-link-type="dfn" href="#resource-representation">resource representation</a>, known as the <strong>protected
resource</strong>. See <a href="#policy-delivery">§3 Policy Delivery</a> for details regarding
the mechanisms by which policies may be applied to a protected
resource.
</dl>
<h3 class="heading settled" data-level="2.2" id="terms-defined-by-reference"><span class="secno">2.2. </span><span class="content">Terms defined by reference</span><a class="self-link" href="#terms-defined-by-reference"></a></h3>
<dl>
<dt>
<dfn data-dfn-type="dfn" data-noexport="" id="globally-unique-identifier">globally unique identifier<a class="self-link" href="#globally-unique-identifier"></a></dfn>
<dd>
Defined in
<a href="https://tools.ietf.org/html/rfc6454#section-2.3">Section 2.3 of
the Origin specification</a>
gitextract_6wec4yj9/ ├── .github/ │ └── workflows/ │ └── auto-publish.yml ├── .gitignore ├── .pr-preview.json ├── 2/ │ ├── index.bs │ └── published/ │ ├── 2015-02-CR.html │ ├── 2015-07-CR.html │ ├── 2015-08-PR.html │ ├── 2016-11-PR.html │ └── default.css ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE.md ├── Makefile ├── README.md ├── WD.html ├── api/ │ └── index.bs ├── cookies/ │ ├── Makefile │ ├── index.bs │ └── published/ │ └── FPWD.html ├── document/ │ ├── Makefile │ └── index.bs ├── iana/ │ ├── Makefile │ ├── draft-west-webappsec-csp-reg-00.html │ ├── draft-west-webappsec-csp-reg-00.txt │ ├── draft-west-webappsec-csp-reg-01.html │ ├── draft-west-webappsec-csp-reg-01.txt │ ├── draft-west-webappsec-csp-reg-02.html │ ├── draft-west-webappsec-csp-reg-02.txt │ ├── draft-west-webappsec-csp-reg-03.html │ ├── draft-west-webappsec-csp-reg-03.txt │ ├── draft-west-webappsec-csp-reg-04.html │ ├── draft-west-webappsec-csp-reg-04.txt │ ├── draft.md │ └── rfc7762.xml ├── index.bs ├── pinning/ │ ├── index.bs │ └── published/ │ ├── 2015-02-FPWD.html │ └── default.css ├── published/ │ ├── 2012-11-15-CSP-1-0-CR.html │ ├── 2014-02-04-CSP-1-1-WD.html │ ├── 2014-07-03-CSP-2-LCWD.html │ ├── 2014-09-03-CSP-2-CR.html │ ├── FPWD-2015-01.html │ └── default.css └── w3c.json
Condensed preview — 45 files, each showing path, character count, and a content snippet. Download the .json file or copy for the full structured content (3,760K chars).
[
{
"path": ".github/workflows/auto-publish.yml",
"chars": 547,
"preview": "name: CI\non:\n pull_request: {}\n push:\n branches: [main]\n\njobs:\n main:\n name: Build, Validate, and Publish\n r"
},
{
"path": ".gitignore",
"chars": 11,
"preview": "index.html\n"
},
{
"path": ".pr-preview.json",
"chars": 97,
"preview": "{\n \"src_file\": \"index.bs\",\n \"type\": \"bikeshed\",\n \"params\": {\n \"force\": 1\n }\n}\n"
},
{
"path": "2/index.bs",
"chars": 165574,
"preview": "<h1>Content Security Policy Level 2</h1>\n<pre class=\"metadata\">\nStatus: ED\nED: https://w3c.github.io/webappsec/specs/CSP"
},
{
"path": "2/published/2015-02-CR.html",
"chars": 287083,
"preview": "<!doctype html>\n<html lang=\"en\">\n <head>\n \n <meta content=\"text/html; charset=utf-8\" http-equiv=\"Content-Type\">\n \n \n"
},
{
"path": "2/published/2015-07-CR.html",
"chars": 283074,
"preview": "<!doctype html>\n<html lang=\"en\">\n <head>\n \n <meta content=\"text/html; charset=utf-8\" http-equiv=\"Content-Type\">\n \n \n"
},
{
"path": "2/published/2015-08-PR.html",
"chars": 281062,
"preview": "<!doctype html>\n<html lang=\"en\">\n <head>\n \n <meta content=\"text/html; charset=utf-8\" http-equiv=\"Content-Type\">\n \n \n"
},
{
"path": "2/published/2016-11-PR.html",
"chars": 283578,
"preview": "\n\n<!doctype html>\n<html lang=\"en\">\n <head>\n \n <meta content=\"text/html; charset=utf-8\" http-equiv=\"Content-Type\">\n <m"
},
{
"path": "2/published/default.css",
"chars": 17186,
"preview": "/*\n * Style sheet for WebAppSec specifications (stolen wholesale from the CSSWG),\n * to be used in addition to http://ww"
},
{
"path": "CODE_OF_CONDUCT.md",
"chars": 186,
"preview": "# Code of Conduct\n\nAll documentation, code and communication under this repository are covered by the [W3C Code of Ethic"
},
{
"path": "CONTRIBUTING.md",
"chars": 1047,
"preview": "Contributions to this repository are intended to become part of Recommendation-track documents governed by the\n[W3C Pate"
},
{
"path": "LICENSE.md",
"chars": 167,
"preview": "All documents in this Repository are licensed by contributors\nunder the \n[W3C Software and Document License](https://www"
},
{
"path": "Makefile",
"chars": 1170,
"preview": "SHELL=/bin/bash\n\nall: index.html ./api/index.html ./cookies/index.html ./pinning/index.html\n\nforce:\n\tbikeshed -f spec ./"
},
{
"path": "README.md",
"chars": 274,
"preview": "Content Security Policy\n=======================\n\nCSP 3 is being specified in `index.bs` (published at <https://www.w3.or"
},
{
"path": "WD.html",
"chars": 615084,
"preview": "<!doctype html><html lang=\"en\">\n <head>\n <meta content=\"text/html; charset=utf-8\" http-equiv=\"Content-Type\">\n <meta co"
},
{
"path": "api/index.bs",
"chars": 15627,
"preview": "<h1>Content Security Policy: API</h1>\n<pre class=\"metadata\">\nStatus: ED\nED: https://w3c.github.io/webappsec-csp/api/\nSho"
},
{
"path": "cookies/Makefile",
"chars": 275,
"preview": "all: index.html\n\nforce:\n\tbikeshed -f spec ./index.src.html\n\nindex.html: index.src.html\n\tbikeshed -f spec ./index.src.htm"
},
{
"path": "cookies/index.bs",
"chars": 12389,
"preview": "<h1>Content Security Policy: Cookie Controls</h1>\n<pre class=\"metadata\">\nStatus: NOTE\nWarning: obsolete\nED: https://w3c."
},
{
"path": "cookies/published/FPWD.html",
"chars": 35517,
"preview": "<!doctype html><html lang=\"en\">\n <head>\n <meta content=\"text/html; charset=utf-8\" http-equiv=\"Content-Type\">\n <title>C"
},
{
"path": "document/Makefile",
"chars": 275,
"preview": "all: index.html\n\nforce:\n\tbikeshed -f spec ./index.src.html\n\nindex.html: index.src.html\n\tbikeshed -f spec ./index.src.htm"
},
{
"path": "document/index.bs",
"chars": 6880,
"preview": "<h1>Content Security Policy: Document Features</h1>\n<pre class=\"metadata\">\nStatus: ED\nED: https://w3c.github.io/webappse"
},
{
"path": "iana/Makefile",
"chars": 908,
"preview": "id_base = ..\nxml2rfc ?= xml2rfc\nkramdown-rfc2629 ?= kramdown-rfc2629\nidnits ?= idnits\n\ntitle = west-webappsec-csp-reg\nla"
},
{
"path": "iana/draft-west-webappsec-csp-reg-00.html",
"chars": 21782,
"preview": "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \n \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">\n\n<html "
},
{
"path": "iana/draft-west-webappsec-csp-reg-00.txt",
"chars": 9762,
"preview": "\n\n\n\nNetwork Working Group M. West\nInternet-Draft "
},
{
"path": "iana/draft-west-webappsec-csp-reg-01.html",
"chars": 21605,
"preview": "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \n \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">\n\n<html "
},
{
"path": "iana/draft-west-webappsec-csp-reg-01.txt",
"chars": 9566,
"preview": "\n\n\n\nNetwork Working Group M. West\nInternet-Draft "
},
{
"path": "iana/draft-west-webappsec-csp-reg-02.html",
"chars": 21732,
"preview": "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \n \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">\n\n<html "
},
{
"path": "iana/draft-west-webappsec-csp-reg-02.txt",
"chars": 9659,
"preview": "\n\n\n\nNetwork Working Group M. West\nInternet-Draft "
},
{
"path": "iana/draft-west-webappsec-csp-reg-03.html",
"chars": 21391,
"preview": "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \n \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">\n\n<html "
},
{
"path": "iana/draft-west-webappsec-csp-reg-03.txt",
"chars": 9523,
"preview": "\n\n\n\nNetwork Working Group M. West\nInternet-Draft "
},
{
"path": "iana/draft-west-webappsec-csp-reg-04.html",
"chars": 21758,
"preview": "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \n \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">\n\n<html "
},
{
"path": "iana/draft-west-webappsec-csp-reg-04.txt",
"chars": 9803,
"preview": "\n\n\n\nNetwork Working Group M. West\nInternet-Draft "
},
{
"path": "iana/draft.md",
"chars": 5427,
"preview": "---\ntitle: Initial Assignment for a Content Security Policy Directive Registry\nabbrev: webappsec-csp-reg\ndocname: draft-"
},
{
"path": "iana/rfc7762.xml",
"chars": 8579,
"preview": "<?xml version=\"1.0\" encoding=\"US-ASCII\"?>\n <?xml-stylesheet type=\"text/xsl\" href=\"rfc2629.xslt\" ?>\n <!-- generated by "
},
{
"path": "index.bs",
"chars": 226127,
"preview": "<h1>Content Security Policy Level 3</h1>\n<pre class=\"metadata\">\nStatus: ED\nED: https://w3c.github.io/webappsec-csp/\nTR: "
},
{
"path": "pinning/index.bs",
"chars": 34207,
"preview": "<h1>Content Security Policy Pinning</h1>\n<pre class=\"metadata\">\nStatus: NOTE\nGroup: WebAppSec\nED: https://w3c.github.io/"
},
{
"path": "pinning/published/2015-02-FPWD.html",
"chars": 75286,
"preview": "<!doctype html>\n<html lang=\"en\">\n <head>\n \n <meta content=\"text/html; charset=utf-8\" http-equiv=\"Content-Type\">\n \n \n"
},
{
"path": "pinning/published/default.css",
"chars": 17186,
"preview": "/*\n * Style sheet for WebAppSec specifications (stolen wholesale from the CSSWG),\n * to be used in addition to http://ww"
},
{
"path": "published/2012-11-15-CSP-1-0-CR.html",
"chars": 60490,
"preview": "<!DOCTYPE html>\n<html>\n <head>\n <title>Content Security Policy 1.0</title>\n <meta http-equiv='Content-Type' conte"
},
{
"path": "published/2014-02-04-CSP-1-1-WD.html",
"chars": 186470,
"preview": "<!DOCTYPE html>\n<html lang=\"en\" dir=\"ltr\" typeof=\"bibo:Document w3p:WD\" about=\"\" property=\"dcterms:language\" content=\"en"
},
{
"path": "published/2014-07-03-CSP-2-LCWD.html",
"chars": 255125,
"preview": "<!DOCTYPE html><html lang=en><head>\n <meta content=\"text/html; charset=utf-8\" http-equiv=Content-Type>\n <title>Content"
},
{
"path": "published/2014-09-03-CSP-2-CR.html",
"chars": 259575,
"preview": "<!DOCTYPE html><html lang=en><head>\n <meta content=\"text/html; charset=utf-8\" http-equiv=Content-Type>\n <title>Content"
},
{
"path": "published/FPWD-2015-01.html",
"chars": 268524,
"preview": "<!doctype html><html lang=\"en\">\n <head>\n <meta content=\"text/html; charset=utf-8\" http-equiv=\"Content-Type\">\n <title>C"
},
{
"path": "published/default.css",
"chars": 17337,
"preview": "/*\n * Style sheet for WebAppSec specifications (stolen wholesale from the CSSWG),\n * to be used in addition to http://ww"
},
{
"path": "w3c.json",
"chars": 118,
"preview": "{\n \"group\": [\n \"49309\"\n ],\n \"contacts\": [\n \"wseltzer\"\n ],\n \"shortName\": \"csp\",\n \"repo-type\": \"rec-track\"\n}"
}
]
About this extraction
This page contains the full source code of the w3c/webappsec-csp GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 45 files (3.4 MB), approximately 896.9k tokens. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.
Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.