Fork the specification into experimental.html for refactoring
authorAdam Barth <w3c@adambarth.com>
Sat, 05 Nov 2011 01:06:26 -0700
changeset 31db6a34dad6cb
parent 30 3b107259a6f8
child 32 d5c9816fc118
Fork the specification into experimental.html for refactoring
experimental.html
     1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/experimental.html	Sat Nov 05 01:06:26 2011 -0700
     1.3 @@ -0,0 +1,1399 @@
     1.4 +<!DOCTYPE html>
     1.5 +<html>
     1.6 +  <head>
     1.7 +    <title>Content Security Policy</title>
     1.8 +    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
     1.9 +    <!--
    1.10 +      === NOTA BENE ===
    1.11 +      For the three scripts below, if your spec resides on dev.w3 you can check them
    1.12 +      out in the same tree and use relative links so that they'll work offline,
    1.13 +     -->
    1.14 +    <script src='js/respec.js' class='remove'></script>
    1.15 +    <script class='remove'>
    1.16 +      var respecConfig = {
    1.17 +          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
    1.18 +          // Member-SUBM
    1.19 +          specStatus:           "unofficial",
    1.20 +
    1.21 +          // the specification's short name, as in http://www.w3.org/TR/short-name/
    1.22 +          shortName:            "CSP",
    1.23 +
    1.24 +          // if your specification has a subtitle that goes below the main
    1.25 +          // formal title, define it here
    1.26 +          // subtitle   :  "an excellent document",
    1.27 +
    1.28 +          // if you wish the publication date to be other than today, set this
    1.29 +          // publishDate:  "2009-08-06",
    1.30 +
    1.31 +          // if the specification's copyright date is a range of years, specify
    1.32 +          // the start date here:
    1.33 +          copyrightStart: "2010",
    1.34 +
    1.35 +          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
    1.36 +          // and its maturity status
    1.37 +          // previousPublishDate:  "1977-03-15",
    1.38 +          // previousMaturity:  "WD",
    1.39 +
    1.40 +          // if there a publicly available Editor's Draft, this is the link
    1.41 +          // edDraftURI:           "http://dev.w3.org/2009/dap/ReSpec.js/documentation.html",
    1.42 +
    1.43 +          // if this is a LCWD, uncomment and set the end of its review period
    1.44 +          // lcEnd: "2009-08-05",
    1.45 +
    1.46 +          // if you want to have extra CSS, append them to this list
    1.47 +          // it is recommended that the respec.css stylesheet be kept
    1.48 +          extraCSS:             ["css/respec.css"],
    1.49 +
    1.50 +          // editors, add as many as you like
    1.51 +          // only "name" is required
    1.52 +          editors:  [
    1.53 +              { name: "Brandon Sterne", url: "mailto:bsterne@mozilla.com",
    1.54 +                company: "Mozilla Corporation", companyURL: "http://www.mozilla.com/" },
    1.55 +              { name: "Adam Barth", url: "mailto:w3c@adambarth.com",
    1.56 +                company: "Google, Inc.", companyURL: "http://www.google.com/" },
    1.57 +          ],
    1.58 +
    1.59 +          // authors, add as many as you like. 
    1.60 +          // This is optional, uncomment if you have authors as well as editors.
    1.61 +          // only "name" is required. Same format as editors.
    1.62 +
    1.63 +          //authors:  [
    1.64 +          //    { name: "Your Name", url: "http://example.org/",
    1.65 +          //      company: "Your Company", companyURL: "http://example.com/" },
    1.66 +          //],
    1.67 +
    1.68 +          // name of the WG
    1.69 +          wg:           "Web Application Security Working Group",
    1.70 +
    1.71 +          // URI of the public WG page
    1.72 +          wgURI:        "http://www.w3.org/2011/webappsec/",
    1.73 +
    1.74 +          // name (with the @w3c.org) of the public mailing to which comments are due
    1.75 +          wgPublicList: "public-web-security@w3.org",
    1.76 +
    1.77 +          // URI of the patent status for this WG, for Rec-track documents
    1.78 +          // !!!! IMPORTANT !!!!
    1.79 +          // This is important for Rec-track documents, do not copy a patent URI from a random
    1.80 +          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
    1.81 +          // Team Contact.
    1.82 +          wgPatentURI:  "",
    1.83 +      };
    1.84 +    </script>
    1.85 +  </head>
    1.86 +  <body>
    1.87 +    <section id='abstract'>
    1.88 +      <p>This document defines a policy language used to declare a set of content restrictions for a
    1.89 +      web resource, and a mechanism for transmitting the policy from a server to a client where the
    1.90 +      policy is enforced.</p>
    1.91 +    </section>
    1.92 +
    1.93 +    <section class="informative">
    1.94 +      <h2>Introduction</h2>
    1.95 +      <p>The purpose of this specification is to provide a method for web applications to broadly
    1.96 +      address a large class of vulnerabilities known as <strong>content injection</strong> which is
    1.97 +      the primary focus of Content Security Policy.  Other threats, such as cross-site request
    1.98 +      forgery, are not a focus of this specification.</p>
    1.99 +
   1.100 +      <p>Content Security Policy is a declarative policy framework that enables web authors and
   1.101 +      server administrators to specify the permitted sources of content in their web applications
   1.102 +      and to restrict the capabilities of that content.  Content Security Policy mitigates and
   1.103 +      detects content injection attacks such as cross-site scripting (XSS).</p>
   1.104 +
   1.105 +      <p>Content Security Policy is not intended to be a fool-proof security system, but it is
   1.106 +      intended to provide an effective layer of security that will dovetail with any site's existing
   1.107 +      web application security program.</p>
   1.108 +
   1.109 +      <p>Content Security Policy is an opt-in mechanism which requires that servers explicitly
   1.110 +      declare a security policy in order to receive any of the protection described in this
   1.111 +      document.  Content Security Policies are applied by the user-agent on a per resource basis, so
   1.112 +      servers must emit a security policy with each resource that the server wants protected.</p>
   1.113 +    </section>
   1.114 +
   1.115 +    <section>
   1.116 +      <h2>Conformance Criteria</h2>
   1.117 +      <p>This specification is written for resource authors and user-agents.  All examples, and
   1.118 +      notes in this specification are non-normative, as are all sections explicitly marked
   1.119 +      non-normative. Everything else in this specification is normative.</p>
   1.120 +
   1.121 +      <p>The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   1.122 +      and "OPTIONAL" in the normative parts of this document are to be interpreted as described in
   1.123 +      RFC 2119. [[!RFC2119]]</p>
   1.124 +
   1.125 +      <p>A conformant user-agent is one that implements all the requirements listed in this
   1.126 +      specification that are applicable to user-agents.</p>
   1.127 +
   1.128 +      <p>A conformant server is one that implements all the requirements listed in this
   1.129 +      specification that are applicable to servers.</p>
   1.130 +
   1.131 +      <section>
   1.132 +        <h3>Terminology</h3>
   1.133 +        <p>This section defines several terms used throughout the document.</p>
   1.134 +
   1.135 +        <p>The term <dfn title="">security policy</dfn>, or simply <dfn title="">policy</dfn>, for
   1.136 +        the purposes of this specification refers to either:
   1.137 +          <ol>
   1.138 +            <li>A set of security preferences for restricting the behavior of content within a
   1.139 +            document or resource</li>
   1.140 +            <li>A fragment of text that codifies these preferences</li>
   1.141 +          </ol>
   1.142 +        </p>
   1.143 +
   1.144 +        <p>A server transmits their security policy for a particular resource as a composition
   1.145 +        of <dfn title="">directives</dfn>, such as <code>default-src 'self'</code>, each of which
   1.146 +        controls a specific set of content capabilities within a document rendered by a user-agent.
   1.147 +        Directives may also be used to specify the locations of resources needed by user-agents to
   1.148 +        process and enforce security policies.  More details are provided in
   1.149 +        the <a href="#directives">directives</a> section.</p>
   1.150 +
   1.151 +        <p>A directive is composed of a <dfn title="">directive name</dfn>, which indicates the
   1.152 +        class of content that is to be restricted by the user-agent, and a <dfn title="">directive
   1.153 +        value</dfn>, which specifies the range of permitted behavior for that content class.</p>
   1.154 +
   1.155 +        <p>Most of the policy directives defined in this document take a list
   1.156 +        of <dfn title="">sources</dfn> as the directive value.  A source is a location, such as a
   1.157 +        network host, from which content of a particular type can be <dfn id="fetch"
   1.158 +        title="">fetched</dfn> according to
   1.159 +        the <a href="http://www.whatwg.org/specs/web-apps/current-work/#fetching-resources">fetching
   1.160 +        algorithm</a> defined in the HTML 5 standard [[!HTML5]].  Sources can be specified according
   1.161 +        to scheme, host and port.</p>
   1.162 +
   1.163 +        <p>Fetching resources requires <dfn id="resolve">resolving</dfn>
   1.164 +        and <dfn id="parse-url">parsing</dfn> URLs.  The algorithms
   1.165 +        for <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#resolving-urls">resolving
   1.166 +        a URL</a>
   1.167 +        and <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#parse-a-url">parsing
   1.168 +        a URL</a> are defined in the HTML 5 standard [[!HTML5]].</p>
   1.169 +
   1.170 +        <p>Content Security Policies are applied by a user-agent on a <strong>per-resource
   1.171 +        basis</strong>.  This means that when a server emits a Content Security Policy in a
   1.172 +        response, the user-agent applies the stated policy to the document returned <strong>in that
   1.173 +        response only</strong> for the lifetime of the document.  That document is often referred to
   1.174 +        in this specification as the <dfn title="">protected document</dfn>
   1.175 +        or <dfn title="">protected resource</dfn>.</p>
   1.176 +
   1.177 +        <p>When Content Security Policy is enabled by a server,
   1.178 +        several <a href="#base-restrictions">base restrictions</a> are applied in the user-agent
   1.179 +        processing model.  These base restrictions provide support for the primary threat model.</p>
   1.180 +
   1.181 +        <p>The term <code>origin</code> is used per its definition in the Origin specification.
   1.182 +          [<em><a href="http://tools.ietf.org/html/draft-abarth-origin-09">ORIGIN</a></em>]</p>
   1.183 +
   1.184 +        <p>The term <code>URI</code> is defined in the URI specification.  [[!URI]]</p>
   1.185 +
   1.186 +        <p>The <code>&lt;script&gt;</code>, <code>&lt;object&gt;</code>, <code>&lt;embed&gt;</code>,
   1.187 +        <code>&lt;img&gt;</code>, <code>&lt;video&gt;</code>, <code>&lt;audio&gt;</code>,
   1.188 +        <code>&lt;link&gt;</code>, <code>&lt;frame&gt;</code> and <code>&lt;iframe&gt;</code>
   1.189 +        elements and the <code>Window</code> object are defined in the HTML 5
   1.190 +        standard. [[!HTML5]].</p>
   1.191 +
   1.192 +        <p>The <code>&lt;applet&gt;</code> element is defined in the HTML 4.01 standard. [[!HTML401]].</p>
   1.193 +
   1.194 +        <p>The <code>@font-face</code> CSS rule is defined in the CSS Fonts Module Level 3 standard.
   1.195 +        [[!CSS3FONT]]</p>
   1.196 +
   1.197 +        <p>The <code>XMLHttpRequest</code> object is defined in the <code>XMLHttpRequest</code>
   1.198 +        standard. [[!XMLHTTPREQUEST]]</p>
   1.199 +
   1.200 +        <p>The <code>WebSocket</code> object is defined in the <code>WebSocket</code>
   1.201 +        standard. [<em><a href="http://dev.w3.org/html5/websockets/">WEBSOCKET</a></em>].</p>
   1.202 +
   1.203 +        <p>The <code>EventSource</code> object is defined in the <code>EventSource</code>
   1.204 +        standard. [<em><a href="http://dev.w3.org/html5/eventsource/">EVENTSOURCE</a></em>].</p>
   1.205 +      </section>
   1.206 +
   1.207 +    </section>
   1.208 +
   1.209 +    <section>
   1.210 +      <h2>Framework</h2>
   1.211 +
   1.212 +      <p>This section defines the general framework for content security
   1.213 +      policies. The next section contains the directive introduced in this
   1.214 +      specification.</p>
   1.215 +    </section>
   1.216 +
   1.217 +    <section>
   1.218 +      <h2>Directives</h2>
   1.219 +
   1.220 +      <p>This section describes the content security policy directives
   1.221 +      introduced in this specification.</p>
   1.222 +    </section>
   1.223 +
   1.224 +    <section>
   1.225 +      <h2>XYZZY</h2>
   1.226 +    </section>
   1.227 +
   1.228 +    <section>
   1.229 +      <h2>Syntax</h2>
   1.230 +      <p>This section defines the syntax and semantics of the policy directives and policy delivery
   1.231 +      mechanisms introduced by this specification.</p>
   1.232 +
   1.233 +      <p>The Augmented Backus-Naur Form (ABNF) notation used in this document is specified in RFC
   1.234 +      5234. [[!ABNF]]</p>
   1.235 +
   1.236 +      <section>
   1.237 +        <h3>Policy Delivery</h3>
   1.238 +          <p>The policy can be delivered from the server to the client via an HTTP response header
   1.239 +          or an HTML <code>meta</code> element.  Both mechanisms indicates that a resource MUST have
   1.240 +          the set of restrictions specified in the policy applied to it by the user-agent while
   1.241 +          rendering the content.</p>
   1.242 +
   1.243 +          <section>
   1.244 +            <h4><code>X-Content-Security-Policy</code> Response Header</h4>
   1.245 +            <p>The policy is transmitted as the HTTP header value and is parsed by the client before
   1.246 +            it receives the response body.</p>
   1.247 +
   1.248 +            <p>The syntax of the HTTP header will be defined in a future specification of the
   1.249 +            IETF <a href="http://tools.ietf.org/wg/websec/">Web Security Working Group</a>.  This
   1.250 +            document assumes a header structure as defined by the following simple ABNF:</p>
   1.251 +            <pre>content-security-policy = "X-Content-Security-Policy:" OWS [ policy ] OWS
   1.252 +OWS                     = *( [ CRLF ] WSP ) ; "optional white space"</pre>
   1.253 +
   1.254 +            <p>where <code>&lt;policy&gt;</code> is a sequence
   1.255 +            of <a href="#directives">directives</a> defined later in this document.  The preceding
   1.256 +            definition includes by reference the core rules <code>CRLF</code> and <code>WSP</code>,
   1.257 +            as defined in [<em><a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">ABNF
   1.258 +            Appendix B.1</a></em>]</p>
   1.259 +
   1.260 +            <p>Content Security Policy can be deployed in <a href="#report-only-mode">report-only
   1.261 +            mode</a> by sending the HTTP response
   1.262 +            header <code>X-Content-Security-Policy-Report-Only</code>.</p>
   1.263 +          </section>
   1.264 +
   1.265 +          <section>
   1.266 +            <h4><code>&lt;meta http-equiv="X-Content-Security-Policy"&gt;</code> HTML Element</h4>
   1.267 +            <p>The policy is transmitted as the <code>content</code> attribute of the element.</p>
   1.268 +
   1.269 +            <p>The Content Security Policy element MUST be placed in the <code>&lt;head&gt;</code>
   1.270 +            element of the document and MUST precede all other <code>&lt;meta&gt;</code> elements in
   1.271 +            order to be treated as valid policy.</p>
   1.272 +
   1.273 +            <p class="issue">There probably need to be additional restrictions placed on what other
   1.274 +            elements cannot precede the policy element due to their parsing causing side effects
   1.275 +            that the policy won't have an opportunity to prevent.</p>
   1.276 +
   1.277 +            <p>Content Security Policy can be deployed in <a href="#report-only-mode">report-only
   1.278 +            mode</a> by placing a <code>&lt;meta
   1.279 +            http-equiv="X-Content-Security-Policy-Report-Only"></code> HTML element in
   1.280 +            the <code>&lt;head></code> section of a document.</p>
   1.281 +
   1.282 +            <p>The semantics of the <code>&lt;meta&gt;</code> and <code>&lt;head&gt;</code> elements
   1.283 +            are defined in the HTML 5 standard. [[!HTML5]]</p>
   1.284 +          </section>
   1.285 +
   1.286 +          <section>
   1.287 +            <h4>Delivery Mechanism Precedence</h4>
   1.288 +            <p>Policies expressed in <code>X-Content-Security-Policy</code> response headers take
   1.289 +            precedence over policies expressed via <code>meta</code> elements.  If
   1.290 +            no <code>X-Content-Security-Policy</code> response headers are present, then the first
   1.291 +            Content Security Policy <code>meta</code> element found in the
   1.292 +            document <code>head</code> takes precedence.</p>
   1.293 +          </section>
   1.294 +
   1.295 +      </section><!-- Policy Delivery -->
   1.296 +
   1.297 +      <section>
   1.298 +        <h3>Directives</h3>
   1.299 +        <p>This section describes the policy directives introduced by this specification.</p>
   1.300 +
   1.301 +        <p>None of the policy directives listed below are required for a policy to be treated as
   1.302 +        valid, though user-agents SHOULD consider a policy containing no recognized directives as a
   1.303 +        processing error and SHOULD report a warning message to the error console communicating that
   1.304 +        a policy containing <a href="#no-recognized-directives">no recognized directives</a> was
   1.305 +        received.</p>
   1.306 +
   1.307 +        <section>
   1.308 +          <h4><code>default-src</code></h4>
   1.309 +          <p>The <code>default-src</code> directive defines the default policy for all types of
   1.310 +          content which are not explicitly restricted by any of the other directives specified in a
   1.311 +          policy.  The directive value represents the default list of sources from which content of
   1.312 +          types not specified elsewhere in the policy may be <a href="#fetch">fetched</a>.
   1.313 +
   1.314 +          <p>An exception to the <code>default-src</code> directive value being used as the default
   1.315 +          policy exists in the case of
   1.316 +          the <a href="#frame-ancestors"><code>frame-ancestors</code></a> directive, which MUST be
   1.317 +          enforced as <code>*</code> (all sources) when not explicitly declared.</p>
   1.318 +
   1.319 +          <p>User-agents MUST enforce the <code>default-src</code> directive for any content request
   1.320 +          which would be restricted by one of the following more specific directives when that
   1.321 +          specific directive is not present in the policy.</p>
   1.322 +        </section>
   1.323 +
   1.324 +        <section>
   1.325 +          <h4><code>script-src</code></h4>
   1.326 +          <p>The <code>script-src</code> directive defines the list of sources from which script
   1.327 +          resources may be fetched as external <code>&lt;script&gt;</code> elements
   1.328 +          or <code>Worker</code> objects in HTML documents or <code>&lt;?xml-stylesheet?&gt;</code>
   1.329 +          processing instructions in XML documents.</p>
   1.330 +
   1.331 +          <p>Prior to a script resource being fetched, the script resource URL MUST first be
   1.332 +          validated as conforming to the protected document's <code>script-src</code> directive.</p>
   1.333 +
   1.334 +          <p>Script resource URLs requiring validation prior to fetching include:
   1.335 +            <ol>
   1.336 +              <li><code>src</code> attributes on <code>&lt;script&gt;</code> elements within HTML
   1.337 +              documents</li>
   1.338 +              <li><code>scriptURL</code> arguments passed to the
   1.339 +              the <a href="http://dev.w3.org/html5/workers/#dedicated-workers-and-the-worker-interface"><code>Worker</code></a>
   1.340 +              and <a href="http://dev.w3.org/html5/workers/#shared-workers-and-the-sharedworker-interface"><code>SharedWorker</code></a>
   1.341 +              constructors within HTML documents</a></li>
   1.342 +              <li><code>href</code> attributes on <code>&lt;xsl:include&gt;</code> elements within
   1.343 +              XML documents</li>
   1.344 +              <li><code>href</code> attributes on <code>&lt;xsl:import&gt;</code> elements within
   1.345 +              XML documents</li>
   1.346 +            </ol>
   1.347 +          </p>
   1.348 +
   1.349 +          <p>Any script resource URLs identified per the above MUST first
   1.350 +          be <a href="#resolve">resolved</a> relative to the containing element and
   1.351 +          then <a href="#parse-url">parsed</a> into its component parts.  The resulting scheme, host
   1.352 +          and port tuple MUST be present in the source list defined by the <code>script-src</code>
   1.353 +          directive in order for the script resource to be requested.</p>
   1.354 +
   1.355 +          <p>User-agents MUST NOT request script resources from non-approved sources.</p>
   1.356 +
   1.357 +          <p>In the case of an XSL transformation, any content to be included into the resulting XML
   1.358 +          document must conform to the original XML document's security policy prior to being
   1.359 +          fetched or loaded.</p>
   1.360 +
   1.361 +          <p>If the <code>script-src</code> directive is not present in a policy and
   1.362 +          the <a href="#default-src"><code>default-src</code></a> directive is present in the
   1.363 +          policy, user-agents MUST subject requests for script resources to
   1.364 +          the <a href="#default-src"><code>default-src</code></a> directive.</p>
   1.365 +        </section>
   1.366 +
   1.367 +        <section>
   1.368 +          <h4><code>object-src</code></h4>
   1.369 +          <p>The <code>object-src</code> directive defines the list of sources from which external
   1.370 +          resources may be fetched when
   1.371 +          constructing <code>&lt;object&gt;</code>, <code>&lt;embed&gt;</code>
   1.372 +          and <code>&lt;applet&gt;</code> elements.</p>
   1.373 +
   1.374 +          <p>Prior to fetching any external resource required by
   1.375 +          an <code>&lt;object&gt;</code>, <code>&lt;embed&gt;</code> or <code>&lt;applet&gt;</code>
   1.376 +          element, the resource URL MUST first be validated as conforming to the protected
   1.377 +          document's <code>object-src</code> directive.</p>
   1.378 +
   1.379 +          <p>Resource URLs requiring validation prior to fetching include:
   1.380 +            <ol>
   1.381 +              <li><code>data</code> attributes on <code>&lt;object&gt;</code> elements</li>
   1.382 +              <li><code>src</code> attributes on <code>&lt;embed&gt;</code> elements</li>
   1.383 +              <li><code>code</code> or <code>archive</code> attributes
   1.384 +              on <code>&lt;applet&gt;</code> elements</li>
   1.385 +            </ol>
   1.386 +          </p>
   1.387 +
   1.388 +          <p class="note">Resource URLs contained in the <code>&lt;applet&gt;</code> element
   1.389 +          attributes listed above may be specified relative to the element's <code>codebase</code>
   1.390 +          attribute or relative to the containing document's base URL.</p>
   1.391 +
   1.392 +          <p>Any <code>&lt;object&gt;</code>, <code>&lt;embed&gt;</code>
   1.393 +          or <code>&lt;applet&gt;</code> resource URLs identified per the above MUST first
   1.394 +          be <a href="#resolve">resolved</a> relative to the containing element and
   1.395 +          then <a href="#parse-url">parsed</a> into its component parts.  The resulting scheme, host
   1.396 +          and port tuple MUST be present in the source list defined by the <code>object-src</code>
   1.397 +          directive in order for the resource URL to be requested.</p>
   1.398 +
   1.399 +          <p>User-agents MUST NOT request <code>&lt;object&gt;</code>, <code>&lt;embed&gt;</code>
   1.400 +          or <code>&lt;applet&gt;</code> resource URLs from non-approved sources.</p>
   1.401 +
   1.402 +          <p>If the <code>object-src</code> directive is not present in a policy and
   1.403 +          the <a href="#default-src"><code>default-src</code></a> directive is present in the
   1.404 +          policy, user-agents MUST subject requests for <code>&lt;object&gt;</code>,
   1.405 +          <code>&lt;embed&gt;</code> and <code>&lt;applet&gt;</code> resources to the
   1.406 +          <a href="#default-src"><code>default-src</code></a> directive.</p>
   1.407 +
   1.408 +          <p class="note">In order to achieve comprehensive XSS protection, sites must include both
   1.409 +          a <code>script-src</code> directive and an <code>object-src</code> directive in their policy, or
   1.410 +          a <code>default-src</code> directive, which covers both cases, due to some plugins having
   1.411 +          scripting capability.</p>
   1.412 +
   1.413 +          <p class="issue">Some plugins, e.g. Google Gears, do not load via URLs.  How
   1.414 +          does <code>object-src</code> interact with these kinds of plugins?</p>
   1.415 +        </section>
   1.416 +
   1.417 +        <section>
   1.418 +          <h4><code>img-src</code></h4>
   1.419 +          <p>The <code>img-src</code> directive defines the list of sources from which images may be
   1.420 +          fetched via <code>&lt;img&gt;</code> elements, CSS properties and shortcut icons,
   1.421 +          a.k.a. favicons.</p>
   1.422 +
   1.423 +          <p>Prior to fetching an image resource, the image resource URL MUST first be validated as
   1.424 +          conforming to the protected document's <code>img-src</code> directive.</p>
   1.425 +
   1.426 +          <p>Resource URLs requiring validation prior to fetching include:
   1.427 +            <ol>
   1.428 +              <li><code>src</code> attributes on <code>&lt;img&gt;</code> elements</li>
   1.429 +              <li><code>url()</code> or <code>image()</code> values on any CSS property that is
   1.430 +              capable of loading an image</li>
   1.431 +              <li><code>href</code> attributes on <code>&lt;link rel="icon"&gt;</code>
   1.432 +              or <code>&lt;link rel="shortcut icon"&gt;</code> elements</li>
   1.433 +            </ol>
   1.434 +          </p>
   1.435 +
   1.436 +          <p>Any resource URLs identified per the above MUST first
   1.437 +          be <a href="#resolve">resolved</a> relative to the <code>&lt;img&gt;</code>
   1.438 +          element, <code>&lt;style&gt;</code> element or external stylesheet URL,
   1.439 +          or <code>&lt;link&gt;</code> element, as appropriate.  Each resolved resource URL must
   1.440 +          then be <a href="#parse-url">parsed</a> into its component parts.  The resulting scheme,
   1.441 +          host and port tuple MUST be present in the source list defined by the <code>img-src</code>
   1.442 +          directive in order for the image resource to be requested.</p>
   1.443 +
   1.444 +          <p>User-agents MUST NOT request image resources from non-approved sources.</p>
   1.445 +
   1.446 +          <p class="issue">Should the user agent fire the error event when one of these loads fails?</p>
   1.447 +
   1.448 +          <p>If the <code>img-src</code> directive is not present in a policy and
   1.449 +          the <a href="#default-src"><code>default-src</code></a> directive is present in the
   1.450 +          policy, user-agents MUST subject requests for image resources to
   1.451 +          the <a href="#default-src"><code>default-src</code></a> directive.</p>
   1.452 +
   1.453 +          <p>The <code>url()</code> and <code>image()</code> notations are defined in the CSS Image
   1.454 +          Values and Replaced Content Module Level 3
   1.455 +          standard. [<em><a href="http://www.w3.org/TR/css3-images/">CSS3-Images</a></em>]</p>
   1.456 +        </section>
   1.457 +
   1.458 +        <section>
   1.459 +          <h4><code>media-src</code></h4>
   1.460 +          <p>The <code>media-src</code> directive defines the list of sources from which external
   1.461 +          resources may be fetched via <code>&lt;video&gt;</code> and <code>&lt;audio&gt;</code>
   1.462 +          elements.</p>
   1.463 +
   1.464 +          <p>Prior to a <code>&lt;video&gt;</code> or <code>&lt;audio&gt;</code> resource being
   1.465 +          fetched, the URL in the element's <code>src</code> attribute MUST first
   1.466 +          be <a href="#resolve">resolved</a> relative to the element and
   1.467 +          then <a href="#parse-url">parsed</a> into its component parts.  The resulting scheme, host
   1.468 +          and port tuple MUST be present in the source list defined by the <code>media-src</code>
   1.469 +          directive in order for the resource to be requested.</p>
   1.470 +
   1.471 +          <p>User-agents MUST NOT request <code>&lt;video&gt;</code> or <code>&lt;audio&gt;</code>
   1.472 +          resources from non-approved sources.</p>
   1.473 +
   1.474 +          <p>If the <code>media-src</code> directive is not present in a policy and
   1.475 +          the <a href="#default-src"><code>default-src</code></a> directive is present in the
   1.476 +          policy, user-agents MUST subject requests for <code>&lt;video&gt;</code>
   1.477 +          and <code>&lt;audio&gt;</code> resources to
   1.478 +          the <a href="#default-src"><code>default-src</code></a> directive.</p>
   1.479 +        </section>
   1.480 +
   1.481 +        <section>
   1.482 +          <h4><code>style-src</code></h4>
   1.483 +          <p>The <code>style-src</code> directive defines the list of sources from which external
   1.484 +          stylesheets may be fetched via <code>&lt;link rel="stylesheet"&gt;</code> elements.</p>
   1.485 +
   1.486 +          <p>Prior to an external stylesheet being fetched, the URL in the <code>href</code>
   1.487 +          attribute of the <code>&lt;link rel="stylesheet"&gt;</code> element MUST first
   1.488 +          be <a href="#resolve">resolved</a> relative to the element and
   1.489 +          then <a href="#parse-url">parsed</a> into its component parts.  The resulting scheme, host
   1.490 +          and port tuple MUST be present in the source list defined by the <code>style-src</code>
   1.491 +          directive in order for the stylesheet to be requested.</p>
   1.492 +
   1.493 +          <p>User-agents MUST NOT request external stylesheets from non-approved sources.</p>
   1.494 +
   1.495 +          <p>If the <code>style-src</code> directive is not present in a policy and
   1.496 +          the <a href="#default-src"><code>default-src</code></a> directive is present in the
   1.497 +          policy, user-agents MUST subject requests for external stylesheets to
   1.498 +          the <a href="#default-src"><code>default-src</code></a> directive.</p>
   1.499 +        </section>
   1.500 +
   1.501 +        <section>
   1.502 +          <h4><code>frame-src</code></h4>
   1.503 +          <p>The <code>frame-src</code> directive defines the list of sources from which resources
   1.504 +          may be fetched via <code>&lt;iframe&gt;</code> elements, and to which hosts
   1.505 +          those <code>&lt;iframe&gt;</code> elements may be navigated.</p>
   1.506 +
   1.507 +          <p>Prior to an <code>&lt;iframe&gt;</code> resource being fetched, the URL in
   1.508 +          the <code>&lt;iframe&gt;</code> element's <code>src</code> attribute MUST first
   1.509 +          be <a href="#resolve">resolved</a> relative to the element and
   1.510 +          then <a href="#parse-url">parsed</a> into its component parts.  The resulting scheme, host
   1.511 +          and port tuple MUST be present in the source list defined by the <code>frame-src</code>
   1.512 +          directive in order for the resource to be requested.</p>
   1.513 +
   1.514 +          <p>Prior to an <code>&lt;iframe&gt;</code> element being navigated, the new location MUST
   1.515 +          first be resolved relative to the element and then parsed into its component parts. The
   1.516 +          resulting scheme, host and port tuple MUST be present in the source list defined by
   1.517 +          the <code>frame-src</code> directive for the navigation to be permitted.</p>
   1.518 +
   1.519 +          <p>User-agents MUST NOT request <code>&lt;iframe&gt;</code> resources from non-approved
   1.520 +          sources nor navigate <code>&lt;iframe&gt;</code> elements to non-approved sources.</p>
   1.521 +
   1.522 +          <p>If the <code>frame-src</code> directive is not present in a policy and
   1.523 +          the <a href="#default-src"><code>default-src</code></a> directive is present in the
   1.524 +          policy, user-agents MUST subject <code>&lt;iframe&gt;</code> requests to
   1.525 +          the <a href="#default-src"><code>default-src</code></a> directive.</p>
   1.526 +        </section>
   1.527 +
   1.528 +        <section>
   1.529 +          <h4><code>font-src</code></h4>
   1.530 +          <p>The <code>font-src</code> directive defines the list of sources from which downloadable
   1.531 +          fonts may be fetched using the <code>@font-face</code> CSS rule.</p>
   1.532 +
   1.533 +          <p>Prior to a font resource being fetched, the <code>url</code> value of
   1.534 +          the <code>src</code> descriptor of the <code>@font-face</code> CSS rule MUST first
   1.535 +          be <a href="#resolve">resolved</a> relative to the <code>&lt;style&gt;</code> element or
   1.536 +          the external stylesheet URL where the <code>@font-face</code> CSS rule is declared. The
   1.537 +          resolved URL MUST then be <a href="#parse-url">parsed</a> into its component parts.  The
   1.538 +          resulting scheme, host and port tuple MUST be present in the source list defined by
   1.539 +          the <code>font-src</code> directive in order for the downloadable font resource to be
   1.540 +          requested.</p>
   1.541 +
   1.542 +          <p>User-agents MUST NOT request downloadable font resources from non-approved sources.</p>
   1.543 +
   1.544 +          <p>If the <code>font-src</code> directive is not present in a policy and
   1.545 +          the <a href="#default-src"><code>default-src</code></a> directive is present in the
   1.546 +          policy, user-agents MUST subject requests for downloadable font resources to
   1.547 +          the <a href="#default-src"><code>default-src</code></a> directive.</p>
   1.548 +        </section>
   1.549 +
   1.550 +        <section>
   1.551 +          <h4><code>connect-src</code></h4>
   1.552 +          <p>The <code>connect-src</code> directive defines the list of sources that are permitted
   1.553 +          to be connected to via the DOM APIs <code>XMLHttpRequest</code>, <code>WebSocket</code>
   1.554 +          and <code>EventSource</code>.</p>
   1.555 +
   1.556 +          <p>Prior to connecting to an external source using one of the restricted APIs, the source
   1.557 +          URL MUST first be validated as conforming to the protected
   1.558 +          document's <code>connect-src</code> directive.</p>
   1.559 +
   1.560 +          <p>Source URLs requiring validation prior to connection include:
   1.561 +            <ol>
   1.562 +              <li>The <code>url</code> argument passed to
   1.563 +              the <a href="http://www.w3.org/TR/XMLHttpRequest/#the-open-method"><code>open()</code>
   1.564 +              method</a> of an <code>XMLHttpRequest</code> object</li>
   1.565 +              <li>The <code>url</code> argument passed to
   1.566 +              the <a href="http://dev.w3.org/html5/websockets/#websocket"><code>WebSocket</code>
   1.567 +              constructor</a></li>
   1.568 +              <li>The <code>url</code> argument passed to
   1.569 +              the <a href="http://dev.w3.org/html5/eventsource/#eventsource"><code>EventSource</code>
   1.570 +              constructor</a></li>
   1.571 +            </ol>
   1.572 +          </p>
   1.573 +
   1.574 +          <p>Any source URLs identified per the above MUST first be
   1.575 +          fully <a href="#resolve">resolved</a>.  In the case of an <code>XMLHttpRequest</code>
   1.576 +          object, the source URL MUST be resolved relative to the
   1.577 +          object's <a href="http://www.w3.org/TR/XMLHttpRequest/#xmlhttprequest-base-url">base
   1.578 +          URL</a>.  In the case of an <code>EventSource</code> object, the source URL MUST be
   1.579 +          resolved relative to
   1.580 +          the <a href="http://www.whatwg.org/specs/web-apps/current-work/#entry-script">entry
   1.581 +          script's</a> <a href="http://www.whatwg.org/specs/web-apps/current-work/#script%27s-base-url">base
   1.582 +          URL</a>.  A <code>WebSocket</code> URL is required to be an absolute URL, and thus does
   1.583 +          not require relative resolution.  Once resolved, the source URL MUST
   1.584 +          be <a href="#parse-url">parsed</a> into its component parts.  The resulting scheme, host
   1.585 +          and port tuple MUST be present in the source list defined by the <code>connect-src</code>
   1.586 +          directive in order for the connection to be made.</p>
   1.587 +
   1.588 +          <p>User-agents MUST NOT connect to any non-approved sources via restricted APIs.</p>
   1.589 +
   1.590 +          <p>If the <code>connect-src</code> directive is not present in a policy and
   1.591 +          the <a href="#default-src"><code>default-src</code></a> directive is present in the
   1.592 +          policy, user-agents MUST subject <code>XMLHttpRequest</code>, <code>WebSocket</code>
   1.593 +          and <code>EventSource</code> connections to
   1.594 +          the <a href="#default-src"><code>default-src</code></a> directive.</p>
   1.595 +        </section>
   1.596 +
   1.597 +        <section>
   1.598 +          <h4><code>frame-ancestors</code></h4>
   1.599 +          <p>The <code>frame-ancestors</code> directive defines the list of sources that are
   1.600 +          permitted to embed the protected resource as
   1.601 +          an <code>&lt;iframe&gt;</code>, <code>&lt;frame&gt;</code> or <code>&lt;object&gt;</code>
   1.602 +          element.</p>
   1.603 +
   1.604 +          <p>If the <code>frame-ancestors</code> directive is present in a policy,
   1.605 +          the <code>location.href</code> attribute for every <code>window</code> in the protected
   1.606 +          document's window parent chain MUST be <a href="#parse-url">parsed</a> into its component
   1.607 +          parts, and the resulting scheme, host and port tuple MUST be present in the source list
   1.608 +          defined by the <code>frame-ancestors</code> directive in order for the protected document
   1.609 +          to be used in the embedded browsing context.</p>
   1.610 +
   1.611 +          <p>If the <code>frame-ancestors</code> directive is not present in a policy its value MUST
   1.612 +          be assumed to be <code>*</code>, or all sources.</p>
   1.613 +
   1.614 +          <p>User-agents MUST NOT render a protected document in an embedded browsing context if
   1.615 +          any <code>window</code> in the protected document's window parent chain has
   1.616 +          a <code>location.href</code> representing a non-approved source.</p>
   1.617 +
   1.618 +          <p class="note">We may want to remove <code>frame-ancestors</code> from Content Security
   1.619 +          Policy as IETF is standardizing an equivalent feature in
   1.620 +          its <a href="http://tools.ietf.org/html/draft-gondrom-frame-options-01">Frame Options</a>
   1.621 +          draft.</p>
   1.622 +        </section>
   1.623 +
   1.624 +        <section>
   1.625 +          <h4><code>report-uri</code></h4>
   1.626 +          <p>The <code>report-uri</code> directive defines one or more URIs to which
   1.627 +          a <a href="#violation-report-syntax">violation report</a> is sent when a policy violation
   1.628 +          occurs.</p>
   1.629 +
   1.630 +          <p>If the <code>report-uri</code> directive is present in a policy the user-agent MUST
   1.631 +          send a violation report to each valid URI specified in the directive value.</p>
   1.632 +
   1.633 +          <p>The violation report MUST be sent via an HTTP POST request whose body is comprised of a
   1.634 +          JSON object containing violation information, and the request MUST have a Content-Type
   1.635 +          of <code>application/json</code>.</p>
   1.636 +
   1.637 +          <p>The URIs specified in the <code>report-uri</code> directive value MUST have the same
   1.638 +          scheme and port as the protected document and MUST share the
   1.639 +          same <em><a href="http://publicsuffix.org/">public suffix</a> +1 DNS label</em> as the
   1.640 +          protected document in order to be treated as valid.</p>
   1.641 +
   1.642 +          <p class="note">Examples of public suffixes include <code>.com</code>, <code>.net</code>
   1.643 +          and <code>.co.uk</code>.  Examples of <em>"public suffix +1 DNS label"</em>
   1.644 +          include <code>example.com</code>, <code>example.net</code> and <code>example.co.uk</code>.
   1.645 +          Therefore a protected document whose host is <code>www.example.com</code> could have
   1.646 +          a <code>report-uri</code> hosted on <code>reports.example.com</code>
   1.647 +          but <b>not</b> <code>reports.example.net</code>.</p>
   1.648 +
   1.649 +          <p>User-agents MUST send <a href="#violation-report-syntax">violation reports</a> to all valid
   1.650 +          URIs listed in the <code>report-uri</code> directive value.</p>
   1.651 +
   1.652 +          <p>User-agents MUST NOT send violation reports to any invalid URIs listed in
   1.653 +          the <code>report-uri</code> directive value.</p>
   1.654 +
   1.655 +          <p>User-agents MUST NOT follow HTTP 3xx redirect responses when sending violation
   1.656 +          reports.</p>
   1.657 +
   1.658 +          <p>User-agents MUST resolve a <code>report-uri</code> relative to the protected document's
   1.659 +          location.</p>
   1.660 +
   1.661 +          <p>User-agents SHOULD log policy violations on the error console when they occur.</p>
   1.662 +
   1.663 +          <p class="issue">This section is very HTTP-centric regarding report sending.  Is it proper
   1.664 +          to require HTTP POST, for instance, if the <code>report-uri</code> uses the ftp: scheme?
   1.665 +          Should non-HTTP schemes be allowed for reports?</p>
   1.666 +        </section>
   1.667 +
   1.668 +        <section>
   1.669 +          <h4><code>policy-uri</code></h4>
   1.670 +          <p>The <code>policy-uri</code> directive defines the location of a file containing the
   1.671 +          policy for a protected resource.  The contents of the file comprise the complete policy
   1.672 +          for the protected resource.</p>
   1.673 +
   1.674 +          <p>The <code>policy-uri</code> directive MUST only be declared in the absence of all other
   1.675 +          policy directives.</p>
   1.676 +
   1.677 +          <p>If the <code>policy-uri</code> directive is present in a policy and no other policy
   1.678 +          directives are declared the user-agent MUST fetch the URI defined in
   1.679 +          the <code>policy-uri</code> directive value and parse the content returned as the complete
   1.680 +          security policy for the protected resource.</p>
   1.681 +
   1.682 +          <p>If the <code>policy-uri</code> directive is present in a policy and any other policy
   1.683 +          directive is also declared the user-agent MUST enforce the policy <code>default-src
   1.684 +          'none'</code>.</p>
   1.685 +
   1.686 +          <p>The URI specified in the <code>policy-uri</code> directive value MUST have the
   1.687 +          same <code>origin</code> as the protected document in order to be treated as valid.</p>
   1.688 +
   1.689 +          <p>User-agents MUST NOT fetch an invalid <code>policy-uri</code> and when one is
   1.690 +          encountered the user-agent MUST enforce the policy <code>default-src 'none'</code>.</p>
   1.691 +
   1.692 +          <p>The response to a <code>policy-uri</code> request MUST include a Content-Type
   1.693 +          of <code>text/x-content-security-policy</code> in order for the response to be treated as
   1.694 +          valid policy for the protected resource.  User-agents MUST NOT enforce a policy retrieved
   1.695 +          from a <code>policy-uri</code> that does not have the required Content-Type and MUST
   1.696 +          enforce the policy <code>default-src 'none'</code> when such a response is
   1.697 +          received.</p>
   1.698 +
   1.699 +          <p>User-agents MUST NOT follow HTTP 3xx redirect responses when fetching
   1.700 +          a <code>policy-uri</code>.</p>
   1.701 +
   1.702 +          <p>User-agents MUST resolve a <code>policy-uri</code> relative to the protected document's
   1.703 +          location.</p>
   1.704 +        </section>
   1.705 +
   1.706 +        <section>
   1.707 +          <h4><code>options</code></h4>
   1.708 +          <p>The <code>options</code> directive defines a set of modifications to the Content
   1.709 +          Security Policy base restrictions.</p>
   1.710 +
   1.711 +          <p>The <code>options</code> directive value is comprised of a space-separated LDH tokens,
   1.712 +          each specifying a modification to the default Content Security Policy processing
   1.713 +          model.</p>
   1.714 +
   1.715 +          <p>User-agents MUST ignore any unrecognized <code>options</code> tokens and when an
   1.716 +          unrecognized <code>options</code> token is encountered, user-agents SHOULD log the event
   1.717 +          on the error console.</p>
   1.718 +        </section>
   1.719 +
   1.720 +      </section><!-- Directives -->
   1.721 +
   1.722 +      <section class="informative">
   1.723 +        <h3>Source Expressions</h3>
   1.724 +        <p>This section describes the structure of the directive values that restrict the loading of
   1.725 +        content into a protected document.</p>
   1.726 +
   1.727 +        <p>A source expression represents a combination of a scheme, a set of hosts, and a network
   1.728 +        port from which content may be loaded.  Source expressions may contain a
   1.729 +        wildcard, <code>*</code>, used to match a set of hosts or a set of ports.</p>
   1.730 +
   1.731 +        <p>A source expression may specify a set of hosts represented by any number of DNS labels
   1.732 +        and an optional leading <a href="#hostname-wildcards">hostname wildcard</a> which matches 0
   1.733 +        or more leading DNS labels.  If 0 DNS labels are specified in the source expression, a
   1.734 +        wildcard represents the set of URIs.</p>
   1.735 +
   1.736 +        <p class="note">Examples of host-only source expressions are <code>example.net</code>
   1.737 +        and <code>*.example.com</code>.</p>
   1.738 +
   1.739 +        <p>Source expressions may specify a scheme and/or port from which content is limited to
   1.740 +        loading from.  Content loading may be restricted to a single scheme by declaring the scheme
   1.741 +        at the beginning of a source expression.  Content loading may also be restricted to a
   1.742 +        particular port by declaring the port number at the end of a source expression.
   1.743 +        A <a href="#port-wildcards">port wildcard</a> <code>*</code> may also be used in place of a
   1.744 +        single port number to permit content from any port.</p>
   1.745 +
   1.746 +        <p>If a scheme is not specified as part of the source expression, a user-agent MUST use the
   1.747 +        same scheme as the protected document.  If a port number is not specified as part of the
   1.748 +        source expression, a user-agent MUST use the default port for the source's scheme, whether
   1.749 +        the scheme was explicitly stated in the source expression or was inherited from the
   1.750 +        protected document.</p>
   1.751 +
   1.752 +        <p class="note">An example of a source expression specifying a scheme restriction
   1.753 +        is <code>https://example.com</code>.  An example of a source expression specifying scheme
   1.754 +        and port restrictions is <code>https://*.example.org:443</code>.</p>
   1.755 +
   1.756 +        <p>A source expression may consist entirely of a scheme.  In this case, user-agents MUST
   1.757 +        only restrict content to be loaded from the specified scheme and MUST NOT apply any host or
   1.758 +        port restrictions.  This allows <a href="#host-less-schemes">host-less schemes</a> to be
   1.759 +        used as sources in security policies.</p>
   1.760 +
   1.761 +        <p>User-agents MUST treat all invalid source expressions encountered in a directive value as
   1.762 +        empty.</p>
   1.763 +
   1.764 +        <p>Servers MUST specify internationalized domain names in security policies according to
   1.765 +        their punycode
   1.766 +        representations. [<em><a href="http://tools.ietf.org/html/rfc3492">RFC 3492</a></em>]</p>
   1.767 +
   1.768 +        <section>
   1.769 +          <h4>Host-less Schemes</h4>
   1.770 +          <p>All source expressions do not require a hostname.  Schemes like <code>data:</code> can
   1.771 +          be used to load inline content and do not require a hostname or port number.</p>
   1.772 +
   1.773 +          <p class="note"><code>data:</code> is an example of a complete and valid source expression
   1.774 +          that specifies neither hostname nor port number and which permits data URIs to be used for
   1.775 +          content loading.</p>
   1.776 +        </section><!-- Host-less Schemes -->
   1.777 +
   1.778 +        <section>
   1.779 +          <h4>Hostname Wildcards</h4>
   1.780 +          <p>A source expression MAY contain a single wildcard character, <code>*</code>, in the
   1.781 +          hostname portion and it MUST be used in place of the left-most, or most specific, DNS
   1.782 +          label.  The wildcard character matches zero or more DNS labels.</p>
   1.783 +
   1.784 +          <p class="note">Examples of <strong>valid</strong> source expressions using hostname
   1.785 +          wildcards include <code>*.example.com</code>, <code>*.org</code> and <code>*</code></p>
   1.786 +
   1.787 +          <p class="note">Examples of <strong>invalid</strong> hostname wildcards use
   1.788 +          include <code>www.*.com</code>, <code>*.example.*</code> and <code>example.*</code></p>
   1.789 +        </section><!-- Hostname Wildcards -->
   1.790 +
   1.791 +        <section>
   1.792 +          <h4>Port Wildcards</h4>
   1.793 +          <p>A source expression MAY contain a single wildcard character, <code>*</code>, in place
   1.794 +          of the port number.  The wildcard character indicates that any port may be used to load
   1.795 +          content.</p>
   1.796 +
   1.797 +          <p class="note">Examples of valid source expressions using the port wildcard
   1.798 +          include <code>example.com:*</code> and <code>http://example.net:*</code>.</p>
   1.799 +
   1.800 +          <p>User-agents MAY prevent content from being loaded via specific ports, even when the
   1.801 +          port wildcard is used, due to security reasons.</p>
   1.802 +        </section><!-- Port Wildcards -->
   1.803 +
   1.804 +        <section>
   1.805 +          <h4>Source Expression Keywords</h4>
   1.806 +          <p>A source expression MAY make use of one of the following keywords which either serves
   1.807 +          as a shorthand replacement for a set of hosts or modifies a default behavior for a
   1.808 +          particular directive.</p>
   1.809 +
   1.810 +          <p>Source expression keywords begin and end with a single-quote character in order to
   1.811 +          differentiate them from network hosts of the same name.</p>
   1.812 +
   1.813 +          <p>The <code>'none'</code> keyword represents the empty set of hosts.  If used, no hosts
   1.814 +          are permitted for that directive.</p>
   1.815 +
   1.816 +          <p>The <code>'self'</code> keyword represents the source serving the protected resource.
   1.817 +          When used, content may be loaded from the scheme, host and port that the protected
   1.818 +          resource was served from.</p>
   1.819 +
   1.820 +          <p>The <code>'unsafe-inline'</code> keyword may be used to enable a particular type of
   1.821 +          content to be loaded inline, or from within the protected resource.  Only a subset of the
   1.822 +          directives support this keyword.  When used, content of the type referenced by the
   1.823 +          containing directive may be loaded inline.  More details regarding which directives
   1.824 +          support this keyword are provided in the <a href="#directives">directives</a> section.</p>
   1.825 +
   1.826 +          <p>The <code>'unsafe-eval'</code> keyword may be used to enable a set of ECMAScript APIs
   1.827 +          that turn strings into code which
   1.828 +          are <a href="#code-must-not-be-created-from-strings">restricted by default</a> when
   1.829 +          the <a href="#script-src"><code>script-src</code></a> directive is
   1.830 +          specified. <a href="#script-src"><code>script-src</code></a> is the only directive that
   1.831 +          supports this keyword.</p>
   1.832 +
   1.833 +          <p>User-agents MUST ignore any unrecognized source expression keywords.</p>
   1.834 +        </section><!-- Source Expression Keywords -->
   1.835 +      </section><!-- Source Expressions -->
   1.836 +
   1.837 +      <section>
   1.838 +        <h3>Formal Policy Grammar</h3>
   1.839 +        <p>This section describes the formal grammar of Content Security Policy using a simple ABNF
   1.840 +        notation.  Each rule in the grammar defines one symbol in the form:</p>
   1.841 +
   1.842 +        <pre>symbol = expression</pre>
   1.843 +
   1.844 +        <p>The expression on the right-hand side of a rule consists of one or more sequences of
   1.845 +        symbols.  A complete sequence represents a possible substitution for the symbol on the
   1.846 +        left-hand side of the rule.  A choice between sequences is indicated by a forward slash "/".
   1.847 +        Expression symbols that do not appear on the left-hand side of any rule are terminal
   1.848 +        symbols.  Sequence groups are enclosed in parentheses "(...)" and are treated as a single,
   1.849 +        ordered element.  Symbol repetitions are preceded by an asterisk "*".  If a minimum number
   1.850 +        of repetitions is required, the asterisk is preceded by that number.</p>
   1.851 +
   1.852 +        <p>The following core rules are included by reference, as defined in
   1.853 +        [<em><a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">ABNF Appendix B.1</a></em>]:
   1.854 +        <code>ALPHA</code> (letters), <code>DIGIT</code> (decimal
   1.855 +        0-9), <code>WSP</code> (white space) and <code>VCHAR</code> (printing
   1.856 +        characters).</p>
   1.857 +
   1.858 +        <section>
   1.859 +          <h4>Content Security Policy Grammar</h4>
   1.860 +          <p>This section defines the general syntax of Content Security Policies as well as some
   1.861 +          grammar symbols used in the <a href="#directive-definitions">directive syntax
   1.862 +          definitions</a>.</p>
   1.863 +          <pre>
   1.864 +policy            = directive-list
   1.865 +
   1.866 +directive-list    = [ directive *( ";" [ directive ] ) ]
   1.867 +
   1.868 +directive         = *WSP [ directive-name [ WSP directive-value ] ]
   1.869 +
   1.870 +directive-name    = 1*( ALPHA / DIGIT / "-" )
   1.871 +
   1.872 +directive-value   = *( WSP / &lt;VCHAR except ";"&gt; )
   1.873 +
   1.874 +source-list       = *WSP [ source *( 1*WSP source ) *WSP ]
   1.875 +                  / *WSP "'none'" *WSP
   1.876 +
   1.877 +source            = scheme ":"
   1.878 +                  / ( [ scheme "://" ] host [ port ] )
   1.879 +                  / "'self'"
   1.880 +                    ; &lt;scheme&gt; production from RFC 3986
   1.881 +
   1.882 +host              = [ "*." ] 1*host-char *( "." 1*host-char )
   1.883 +                  / "*"
   1.884 +
   1.885 +host-char         = ALPHA / DIGIT / "-"
   1.886 +
   1.887 +port              = ":" ( 1*DIGIT / "*" )
   1.888 +
   1.889 +option-value      = 1*( ALPHA / DIGIT / "-" )
   1.890 +</pre>
   1.891 +        </section><!-- Content Security Policy Grammar -->
   1.892 +
   1.893 +        <section>
   1.894 +          <h4>Directive Definitions</h4>
   1.895 +          <p>This section defines the syntax of each <code>directive</code> introduced by this
   1.896 +          specification.</p>
   1.897 +          <pre>
   1.898 +default-src       = "default-src" [ WSP source-list ]
   1.899 +
   1.900 +script-src        = "script-src" [ WSP source-list ]
   1.901 +
   1.902 +object-src        = "object-src" [ WSP source-list ]
   1.903 +
   1.904 +img-src           = "img-src" [ WSP source-list ]
   1.905 +
   1.906 +media-src         = "media-src" [ WSP source-list ]
   1.907 +
   1.908 +style-src         = "style-src" [ WSP source-list ]
   1.909 +
   1.910 +frame-src         = "frame-src" [ WSP source-list ]
   1.911 +
   1.912 +font-src          = "font-src" [ WSP source-list ]
   1.913 +
   1.914 +connect-src       = "connect-src" [ WSP source-list ]
   1.915 +
   1.916 +frame-ancestors   = "frame-ancestors" [ WSP source-list ]
   1.917 +
   1.918 +report-uri        = "report-uri" *( 1*WSP &lt;URI&gt; ) *WSP
   1.919 +                    ; &lt;URI&gt; production from RFC 2396
   1.920 +
   1.921 +policy-uri        = "policy-uri" 1*WSP &lt;URI&gt; *WSP
   1.922 +                    ; &lt;URI&gt; production from RFC 2396
   1.923 +
   1.924 +options           = "options" *( 1*WSP option-value ) *WSP
   1.925 +</pre>
   1.926 +
   1.927 +        </section><!-- Directive Definitions -->
   1.928 +      </section><!-- Formal Policy Grammar -->
   1.929 +
   1.930 +      <section class="informative">
   1.931 +        <h3>Sample Policy Definitions</h3>
   1.932 +        <p>This section provides some sample use cases and accompanying security policies.</p>
   1.933 +
   1.934 +        <p><strong>Example 1:</strong> A server wants all content to come from its own domain:</p>
   1.935 +        <pre>X-Content-Security-Policy: default-src 'self'</pre>
   1.936 +
   1.937 +        <p><strong>Example 2:</strong> An auction site wants to allow images from anywhere, plugin
   1.938 +        content from a list of trusted media providers including a content distribution network, and
   1.939 +        scripts only from a server under its control hosting sanitized ECMAScript:</p>
   1.940 +        <pre>X-Content-Security-Policy: default-src 'self'; img-src *; \
   1.941 +                           object-src media1.example.com media2.example.com *.cdn.example.com; \
   1.942 +                           script-src trustedscripts.example.com</pre>
   1.943 +
   1.944 +        <p><strong>Example 3:</strong> A site operations group wants to globally deny all
   1.945 +        third-party scripts in the site, and a particular project team wants to also disallow
   1.946 +        third-party media in their section of the site.  Site operations sends the first header
   1.947 +        while the project team sends the second header, and the user-agent takes the intersection of
   1.948 +        the two headers to form the complete interpreted policy:</p>
   1.949 +        <pre>X-Content-Security-Policy: default-src *; script-src 'self'
   1.950 +X-Content-Security-Policy: default-src *; script-src 'self'; media-src 'self'</pre>
   1.951 +
   1.952 +        <p><strong>Example 4:</strong> Online banking site wants to ensure that all of the content
   1.953 +        in its pages is loaded over TLS to prevent attackers from eavesdropping on insecure content
   1.954 +        requests:</p>
   1.955 +        <pre>X-Content-Security-Policy: default-src https://*:443</pre>
   1.956 +      </section><!-- Sample Policy Definitions -->
   1.957 +
   1.958 +      <section>
   1.959 +        <h3>Violation Report Syntax</h3>
   1.960 +        <p>This section defines the structure of the violation report sent by a user-agent when a
   1.961 +        protected resource's security policy is violated.</p>
   1.962 +
   1.963 +        <p>A user-agent MUST send a violation report in the following two cases:</p>
   1.964 +        <ol>
   1.965 +          <li>Whenever ANY policy violation occurs, a user-agent MUST dispatch
   1.966 +          a <code>SecurityViolation</code> event which does not bubble and is not cancelable at
   1.967 +          the <code>Document</code> object of the protected resource.</li>
   1.968 +          <li>Whenever a policy violation occurs and the server's policy contains
   1.969 +          a <code>report-uri</code>, a user-agent MUST send a violation report to all valid report
   1.970 +          URIs declared in the policy via an HTTP POST request bearing the
   1.971 +          Content-Type <code>application/json</code>.</li>
   1.972 +        </ol>
   1.973 +
   1.974 +        <p>The <code>SecurityViolation</code> DOM event and the violation report sent by a
   1.975 +        user-agent convey the same information about the policy violation and are intended to be
   1.976 +        utilized by the server for monitoring and logging.</p>
   1.977 +
   1.978 +        <p>The <code>SecurityViolation</code> event uses the <code>CustomEvent</code> interface
   1.979 +        defined in the DOM Level 3 Events specification. [[!DOM-LEVEL-3-EVENTS]].</p>
   1.980 +
   1.981 +        <p>The report structure defined below is a JSON object used for both the <code>detail</code>
   1.982 +        argument to the <code>SecurityViolation</code> event constructor and the request body of the
   1.983 +        violation report.</p>
   1.984 +
   1.985 +        <p>The <code>SecurityViolation</code> event <code>detail</code> and the report body sent by
   1.986 +        the user-agent MUST be comprised of a JSON object having the following properties:</p>
   1.987 +
   1.988 +        <ul>
   1.989 +          <li><strong><code>request</code></strong>: HTTP request line of the protected resource
   1.990 +          whose policy was violated including method, URI and HTTP version</li>
   1.991 +          <li><strong><code>request-headers</code></strong>: HTTP request headers sent with the
   1.992 +          request for the protected resource whose policy was violated</li>
   1.993 +          <li><strong><code>blocked-uri</code></strong>: URI of the resource that was prevented from
   1.994 +          loading due to the policy violation</li>
   1.995 +          <li><strong><code>violated-directive</code></strong>: The policy directive that was
   1.996 +          violated</li>
   1.997 +          <li><strong><code>original-policy</code></strong>: The original policy as received by the
   1.998 +          user-agent.  If the policy was received via more than one Content Security Policy response
   1.999 +          header, this field MUST contain a comma separated list of original policies.</li>
  1.1000 +        </ul>
  1.1001 +
  1.1002 +        <p>If the origin of the blocked-uri is not the same as the document's
  1.1003 +        origin, then the user agent MUST replace the blocked-uri with the
  1.1004 +        ASCII serialization of the blocked-uri's origin.</p>
  1.1005 +
  1.1006 +        <p>In the case where a protected resource is not rendered because
  1.1007 +        its <code>frame-ancestors</code> directive is violated, user-agents MUST NOT
  1.1008 +        send <code>blocked-uri</code> in the report as it is assumed to have the same value
  1.1009 +        as <code>request</code>.</p>
  1.1010 +
  1.1011 +        <h4>Sample Policy Violation Report</h4>
  1.1012 +        <p>In the following example a page located at <code>http://example.org/page.html</code> was
  1.1013 +        requested and returned with its response a policy of <code>default-src 'self'; report-uri
  1.1014 +        http://example.org/csp-report.cgi</code>.  The policy was violated by an image element
  1.1015 +        from <code>evil.example.com</code> which had been embedded in the page.</p>
  1.1016 +
  1.1017 +        <pre>{
  1.1018 +  "csp-report": {
  1.1019 +    "request": "GET http://example.org/page.html HTTP/1.1",
  1.1020 +    "request-headers": "Host: example.org
  1.1021 +                        User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre
  1.1022 +                        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  1.1023 +                        Accept-Language: en-us,en;q=0.5
  1.1024 +                        Accept-Encoding: gzip, deflate
  1.1025 +                        Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
  1.1026 +                        Keep-Alive: 115
  1.1027 +                        Proxy-Connection: keep-alive
  1.1028 +                        Cache-Control: max-age=0",
  1.1029 +    "blocked-uri": "http://evil.example.com/image.png",
  1.1030 +    "violated-directive": "default-src http://example.org"
  1.1031 +  }
  1.1032 +}</pre>
  1.1033 +
  1.1034 +        <p class="note">In the above sample report the <code>violated-directive</code> field was
  1.1035 +        sent in the way it was interpreted by the user-agent.  The directive was made explicit by
  1.1036 +        replacing the keyword <code>'self'</code> with the explicit host name of the protected
  1.1037 +        resource.  This is recommended behavior for user-agents as it reduces ambiguity, making
  1.1038 +        policy violations easier to trace by server admins.</p>
  1.1039 +      </section><!-- Violation Report Syntax -->
  1.1040 +
  1.1041 +    </section><!-- Syntax -->
  1.1042 +
  1.1043 +    <section>
  1.1044 +      <h2>User-Agent Behavior</h2>
  1.1045 +      <p>This section describes required behavior for conformant user-agents when processing a
  1.1046 +      Content Security Policy and applying restrictions to a protected resource.</p>
  1.1047 +
  1.1048 +      <section>
  1.1049 +        <h3>Base Restrictions</h3>
  1.1050 +        <p>The following restrictions MUST be applied by a user-agent rendering a protected resource
  1.1051 +        which has declared a Content Security Policy containing at least one valid directive, except
  1.1052 +        in cases where the policy includes directives which disable or modify the restrictions.</p>
  1.1053 +
  1.1054 +        <section>
  1.1055 +          <h4>data: URIs MUST NOT be permitted</h4>
  1.1056 +          <p>User-agents MUST prevent data: URIs from being used to load inline content unless the
  1.1057 +          protected document's policy explicitly permits the data: protocol for that type of
  1.1058 +          content.</p>
  1.1059 +
  1.1060 +          <p>If a protected resource's policy declares
  1.1061 +          a <a href="#report-uri"><code>report-uri</code></a> and this base restriction is violated,
  1.1062 +          user-agents MUST generate a <a href="#violation-report">violation report</a> with fields
  1.1063 +          set appropriately to describe the violation and MUST send the report to
  1.1064 +          the <code>report-uri</code> specified in the policy.</p>
  1.1065 +
  1.1066 +          <h5>Enabling data: URIs</h5>
  1.1067 +          <p>Inline content can be loaded via data: URIs by adding
  1.1068 +          the <a href="#host-less-schemes">data: source expression</a> to the directive that
  1.1069 +          restricts that particular type of content.</p>
  1.1070 +
  1.1071 +          <p class="note">For example, a site that wishes to load inline images via data: URIs would
  1.1072 +          add the directive <code>img-src data:</code> to their policy.</p>
  1.1073 +        </section><!-- data: URIs MUST NOT be permitted -->
  1.1074 +
  1.1075 +        <section>
  1.1076 +          <h4>CSS-ECMAScript bindings MUST come from chrome: or resource: URIs</h4>
  1.1077 +          <p>User-agents which allow external ECMAScript content to be bound to document elements
  1.1078 +          via CSS rules MUST prevent such bindings unless the external content is served as a
  1.1079 +          chrome: or resource: URI.</p>
  1.1080 +
  1.1081 +          <p class="note">An example of such a CSS-ECMAScript binding technology is XBL.
  1.1082 +          [[!XBL]]</p>
  1.1083 +
  1.1084 +          <p class="note">This restriction prevents untrusted remote content from being injected
  1.1085 +          into a document via a stylesheet because both the chrome: and resource: protocols serve
  1.1086 +          only local, trusted content.</p>
  1.1087 +
  1.1088 +          <p>If a protected resource's policy declares
  1.1089 +          a <a href="#report-uri"><code>report-uri</code></a> and this base restriction is violated,
  1.1090 +          user-agents MUST generate a <a href="#violation-report">violation report</a> with fields
  1.1091 +          set appropriately to describe the violation and MUST send the report to
  1.1092 +          the <code>report-uri</code> specified in the policy.</p>
  1.1093 +        </section><!-- ECMAScript bindings to CSS MUST come from chrome: or resource: URIs -->
  1.1094 +
  1.1095 +      </section><!-- Base Restrictions -->
  1.1096 +
  1.1097 +      <section>
  1.1098 +        <h3>Script Execution Restrictions</h3>
  1.1099 +        <p>This section describes required restrictions which MUST be applied by a user-agent
  1.1100 +        rendering a protected resource which has declared ANY directive which controls the loading
  1.1101 +        of ECMAScript content into the protected resource.  Such directives
  1.1102 +        include: <a href="#script-src"><code>script-src</code></a>
  1.1103 +        and <a href="#object-src"><code>object-src</code></a>, as well as an implied value for
  1.1104 +        either of these directives as indicated by
  1.1105 +        a <a href="#default-src"><code>default-src</code></a> directive.  If
  1.1106 +        a <code>script-src</code> directive has not been declared in the policy a user-agent MUST NOT
  1.1107 +        enforce the following restrictions.</p>
  1.1108 +
  1.1109 +        <p class="issue">It may be preferable to only activate these restrictions
  1.1110 +        when <code>script-src</code> is declared.</p>
  1.1111 +
  1.1112 +        <section>
  1.1113 +          <h4>Inline scripts MUST NOT execute</h4>
  1.1114 +          <p>User-agents MUST prevent inline scripts from executing.  These include:</p>
  1.1115 +          <ul>
  1.1116 +            <li>Contents of internal <code>&lt;script&gt;</code> elements</li>
  1.1117 +            <li>javascript: URIs</li>
  1.1118 +            <li>Event-handling HTML attributes</li>
  1.1119 +          </ul>
  1.1120 +
  1.1121 +          <p>The supported method for executing ECMAScript in a protected document is to include
  1.1122 +          <code>&lt;script&gt;</code> elements in the document whose sources are permitted by the
  1.1123 +          protected document's policy.  User-agents MUST execute all external scripts
  1.1124 +          whose <code>src</code> attribute refers to a permitted source and which are served with a
  1.1125 +          Content-Type of <code>application/javascript</code> or <code>application/json</code>.</p>
  1.1126 +
  1.1127 +          <p>If a protected resource's policy declares
  1.1128 +          a <a href="#report-uri"><code>report-uri</code></a> and this restriction is violated,
  1.1129 +          user-agents MUST generate a <a href="#violation-report">violation report</a> and MUST send
  1.1130 +          the report to the <code>report-uri</code> specified in the policy.</p>
  1.1131 +
  1.1132 +          <h5>Enabling inline scripts</h5>
  1.1133 +          <p>Inline script can be enabled by adding
  1.1134 +          the <code>'unsafe-inline'</code> <a href="#source-expression-keywords">source expression
  1.1135 +          keyword</a> to the <a href="#script-src"><code>script-src</code></a> directive.  It is not
  1.1136 +          recommended to do so, however, as all cross-site scripting protection provided by Content
  1.1137 +          Security Policy will be effectively disabled.</p>
  1.1138 +
  1.1139 +          <p class="issue">There is an
  1.1140 +          alternate <a href="http://lists.w3.org/Archives/Public/public-web-security/2011Apr/0033.html">proposal</a>
  1.1141 +          for enabling inline script by Collin Jackson which uses
  1.1142 +          an <code>'inline'</code> <a href="#source-expression-keywords">source expression
  1.1143 +          keyword</a> in <code>script-src</code> but ignores it
  1.1144 +          unless <code>disable-xss-protection</code> is declared as
  1.1145 +          an <a href="#options"><code>options</code></a> token.</p>
  1.1146 +        </section><!-- Inline scripts MUST NOT execute -->
  1.1147 +
  1.1148 +        <section>
  1.1149 +          <h4>Code MUST NOT be created from strings</h4>
  1.1150 +          <p>User-agents MUST prevent strings from being converted to ECMAScript code, including
  1.1151 +          calls to:</p>
  1.1152 +          <ul>
  1.1153 +            <li><code>eval()</code>. Instead of evaluating their arguments,
  1.1154 +            both operator <code>eval</code> and function <code>eval</code>
  1.1155 +            MUST throw a security exception.</li>
  1.1156 +
  1.1157 +            <li><code>new Function()</code>. When called as a constructor, the
  1.1158 +            <code>Function</code> function MUST throw a security exception.</li>
  1.1159 +
  1.1160 +            <li><code>setTimeout()</code>. When called with a first argument
  1.1161 +            that is non-callable (e.g., not a function), the
  1.1162 +            <code>setTimeout</code> function MUST return zero without creating
  1.1163 +            a timer.</li>
  1.1164 +
  1.1165 +            <li><code>setInterval()</code>. When called with a first argument
  1.1166 +            that is non-callable (e.g., not a function), the
  1.1167 +            <code>setInterval</code> function MUST return zero without creating
  1.1168 +            a timer.</li>
  1.1169 +          </ul>
  1.1170 +
  1.1171 +          <p class="issue">Should <code>setTimeout</code> and
  1.1172 +          <code>setInterval</code> throw security exceptions rather than
  1.1173 +          returning zero?</p>
  1.1174 +
  1.1175 +          <p>The term <dfn title="">callable</dfn> refers to an object whose interface has one or
  1.1176 +          more <dfn title="">callers</dfn> as defined in
  1.1177 +          the <a href="http://www.w3.org/TR/2010/WD-WebIDL-20101021/#idl-callers">Web IDL</a>
  1.1178 +          specification [[!WEBIDL]].</p>
  1.1179 +
  1.1180 +          <p>If a protected resource's policy declares
  1.1181 +          a <a href="#report-uri"><code>report-uri</code></a> and this restriction is violated,
  1.1182 +          user-agents MUST generate a <a href="#violation-report">violation report</a> and MUST send
  1.1183 +          the report to the <code>report-uri</code> specified in the policy.</p>
  1.1184 +
  1.1185 +          <h5>Enabling strings-into-code functionality</h5>
  1.1186 +          <p>The APIs listed above that turn strings into executable code can be enabled by adding
  1.1187 +          the <code>'unsafe-eval'</code> <a href="#source-expression-keywords">source expression
  1.1188 +          keyword</a> to the <a href="#script-src"><code>script-src</code></a> directive.  It is not
  1.1189 +          recommended to do so, however, as the risk of DOM-based cross-site scripting will be
  1.1190 +          greatly increased.</p>
  1.1191 +        </section><!-- Code MUST NOT be created from strings -->
  1.1192 +
  1.1193 +      </section><!-- Script Execution Restrictions -->
  1.1194 +
  1.1195 +      <section>
  1.1196 +        <h3>Inline CSS Restrictions</h3>
  1.1197 +        <p>This section describes required restrictions which MUST be applied by a user-agent
  1.1198 +        rendering a protected resource which has declared
  1.1199 +        a <a href="#style-src"><code>style-src</code></a> directive, or has implied
  1.1200 +        a <code>style-src</code> directive by declaring
  1.1201 +        a <a href="#default-src"><code>default-src</code></a> directive.  If
  1.1202 +        a <code>style-src</code> directive has not been declared in the policy a user-agent MUST NOT
  1.1203 +        enforce the following restrictions.</p>
  1.1204 +
  1.1205 +        <section>
  1.1206 +          <h4>Inline CSS MUST NOT be applied</h4>
  1.1207 +          <p>User-agents MUST prevent inline CSS from being applied to the protected document.  This
  1.1208 +          includes CSS properties defined in:</p>
  1.1209 +          <ul>
  1.1210 +            <li><code>&lt;style&gt;</code> elements</li>
  1.1211 +            <li><code>style</code> attributes on HTML elements</li>
  1.1212 +          </ul>
  1.1213 +
  1.1214 +          <p>The supported method for applying CSS properties to a protected resource which utilizes
  1.1215 +          the <code>style-src</code> directive is to include <code>&lt;link
  1.1216 +          rel="stylesheet"&gt;</code> elements in the document whose sources are permitted by the
  1.1217 +          protected document's policy.  User-agents MUST parse and apply all style properties from
  1.1218 +          external stylesheets whose <code>href</code> attribute refers to a permitted source.</p>
  1.1219 +
  1.1220 +          <p>If a protected resource's policy declares
  1.1221 +          a <a href="#report-uri"><code>report-uri</code></a> and this restriction is violated,
  1.1222 +          user-agents MUST generate a <a href="#violation-report">violation report</a> and MUST send
  1.1223 +          the report to the <code>report-uri</code> specified in the policy.</p>
  1.1224 +
  1.1225 +          <h5>Enabling inline CSS</h5>
  1.1226 +          <p>Inline CSS can be enabled by adding
  1.1227 +          the <code>'unsafe-inline'</code> <a href="#source-expression-keywords">source expression
  1.1228 +          keyword</a> to the <a href="#style-src"><code>style-src</code></a> directive.</p>
  1.1229 +        </section><!-- Inline CSS MUST NOT be applied -->
  1.1230 +
  1.1231 +      </section><!-- Inline CSS Restrictions -->
  1.1232 +
  1.1233 +      <section>
  1.1234 +        <h3>Interpreting Multiple Policies</h3>
  1.1235 +        <p>When multiple instances of the Content Security Policy response header are present in a
  1.1236 +        single HTTP response, the user-agent MUST enforce the most restrictive intersection of the
  1.1237 +        policies received.  This means that no action can be taken by the user-agent when rendering
  1.1238 +        the protected document unless every policy directive of every policy header received permits
  1.1239 +        such an action.  If an action taken by a user-agent will violate any of the policy
  1.1240 +        directives received in any response header, that action MUST NOT be taken by the
  1.1241 +        user-agent.</p>
  1.1242 +
  1.1243 +        <p class="issue">Is a description of a policy intersection algorithm necessary?</p>
  1.1244 +
  1.1245 +        <p>When differing <code>report-uri</code> values are received in multiple policy headers the
  1.1246 +        intersection of the policy values is NOT taken.  Rather, user-agents MUST send a single
  1.1247 +        report to each valid URI specified in any <code>report-uri</code> directive received in a
  1.1248 +        policy header.</p>
  1.1249 +
  1.1250 +        <p>When multiple Content Security Policy <code>&lt;meta></code> elements are present in
  1.1251 +        the <code>head</code> section of a protected resource, the first <code>&lt;meta></code>
  1.1252 +        element MUST be parsed as the document's security policy and enforced.  All subsequent
  1.1253 +        policy <code>&lt;meta></code> elements MUST be ignored by the user-agent.</p>
  1.1254 +
  1.1255 +        <p class="issue">What should happen when multiple instances of the same directive but with
  1.1256 +        different values occur within a single policy header or meta element, i.e. should they be
  1.1257 +        combined or intersected as they are successively parsed?</p>
  1.1258 +      </section><!-- Interpreting Multiple Policies -->
  1.1259 +
  1.1260 +      <section>
  1.1261 +        <h3>Handling Policy Parsing Errors</h3>
  1.1262 +        <p>This section describes how user-agents should handle various error conditions encountered
  1.1263 +        when parsing Content Security Policies.  The error conditions described in this section are
  1.1264 +        distinct from the policy violations described earlier in this document.  While policy
  1.1265 +        violations MUST be reported to servers when a <code>policy-uri</code> has been declared,
  1.1266 +        policy parsing warnings SHOULD be reported locally in the user-agent's error console, and
  1.1267 +        SHOULD NOT be reported to the remote server.</p>
  1.1268 +
  1.1269 +        <section>
  1.1270 +          <h4>Unrecognized Directive</h4>
  1.1271 +          <p>When a user-agent receives a directive name that it does not recognize, the user-agent
  1.1272 +          MUST not parse the directive name or value and MUST skip ahead to the next directive name
  1.1273 +          present in the policy or to the end of the policy if no further directives are declared.
  1.1274 +          The user-agent SHOULD report a warning message to the error console containing the
  1.1275 +          unrecognized directive name.</p>
  1.1276 +        </section><!-- Unrecognized Directive -->
  1.1277 +
  1.1278 +        <section>
  1.1279 +          <h4>Invalid Directive</h4>
  1.1280 +          <p>When a user-agent receives a directive name that violates all of
  1.1281 +          the <a href="#directive-definitions">directive syntax</a>, the user-agent MUST not parse
  1.1282 +          the directive name or value and MUST skip ahead to the next directive name present in the
  1.1283 +          policy or to the end of the policy if no further directives are declared.  The user-agent
  1.1284 +          SHOULD report a warning message to the error console containing the invalid directive
  1.1285 +          name.</p>
  1.1286 +        </section><!-- Invalid Directive -->
  1.1287 +
  1.1288 +        <section>
  1.1289 +          <h4>Unrecognized <code>options</code> Token</h4>
  1.1290 +          <p>When a user-agent receives a token in an <code>options</code> directive that it does
  1.1291 +          not recognize, the user-agent MUST skip over it.  User-agents SHOULD report a warning
  1.1292 +          message to the error console containing the unrecognized token.</p>
  1.1293 +        </section><!-- Unrecognized options Token -->
  1.1294 +
  1.1295 +        <section>
  1.1296 +          <h4>Directive Syntax Error</h4>
  1.1297 +          <p>When a user-agent receives a policy directive that
  1.1298 +          violates <a href="#formal-policy-grammar">Content Security Policy syntax</a>, the
  1.1299 +          user-agent MUST discard the entire policy and enforce a policy of <code>default-src
  1.1300 +          'none'</code> on the protected resource.  User-agents SHOULD report a warning message to
  1.1301 +          the error console communicating that an invalid policy was received.</p>
  1.1302 +        </section><!-- Directive Syntax Error -->
  1.1303 +
  1.1304 +        <section>
  1.1305 +          <h4>No Recognized Directives</h4>
  1.1306 +          <p>When a user-agent receives a policy that contains no directives recognized by the
  1.1307 +          user-agent, the user-agent MUST NOT enforce any restrictions on the protected resource.
  1.1308 +          User-agents SHOULD report a warning message to the error console communicating that a
  1.1309 +          policy containing no valid directives was received.</p>
  1.1310 +        </section><!-- No Recognized Directives -->
  1.1311 +
  1.1312 +        <section>
  1.1313 +          <h4>Other Parsing Errors</h4>
  1.1314 +          <p>Any other parsing errors not described in the above sections MUST result in the
  1.1315 +          user-agent enforcing a policy of <code>default-src 'none'</code> on the protected resource
  1.1316 +          and SHOULD result in the user-agent reporting a warning message to the error console
  1.1317 +          describing the error.</p>
  1.1318 +        </section><!-- Other Parsing Errors -->
  1.1319 +
  1.1320 +      </section><!-- Handling Policy Parsing Errors -->
  1.1321 +
  1.1322 +      <section>
  1.1323 +        <h3>Report-Only Mode</h3>
  1.1324 +        <p>This section describes a mode of operation for user-agents in which security policies are
  1.1325 +        parsed and violations are logged as they occur, but without blocking content from loading or
  1.1326 +        executing as the user-agent would under normal processing of Content Security Policy.</p>
  1.1327 +
  1.1328 +        <p>Content Security Policy can be deployed by servers in report-only mode by sending
  1.1329 +        a <code>X-Content-Security-Policy-Report-Only</code> <a href="#x-content-security-policy-response-header">response
  1.1330 +        header</a> or by placing a <code>&lt;meta
  1.1331 +        http-equiv="X-Content-Security-Policy-Report-Only"></code> <a href="#meta-http-equiv--x-content-security-policy---html-element">policy
  1.1332 +        element</a> in the <code>&lt;head></code> section of a document.</p>
  1.1333 +
  1.1334 +        <p>When report-only mode is enabled by a server, the user-agent MUST log all policy
  1.1335 +        violations and policy parsing errors in the same manner that it would in normal blocking
  1.1336 +        mode, including sending <a href="#violation-reports">violation reports</a> to the server if
  1.1337 +        a <a href="#report-uri">report-uri</a> directive is present, as well as logging any
  1.1338 +        appropriate errors or warnings locally to the error console.  In report-only mode, the
  1.1339 +        user-agent MUST NOT prevent any content from loading or executing normally due to violations
  1.1340 +        of the protected document's stated security policy.</p>
  1.1341 +
  1.1342 +        <p class="note">This mode of operation is intended to ease deployment for servers that want
  1.1343 +        to experiment with a security policy but aren't ready to take the step of policy
  1.1344 +        enforcement.  Such sites can develop a security policy according to their knowledge and
  1.1345 +        assumptions about how the site functions and receive reports when content in the site
  1.1346 +        behaves in a manner contrary to the developed policy.  Report-only mode can also be used in
  1.1347 +        parallel with blocking mode as it is a useful test vehicle for a stricter policy.  The
  1.1348 +        stricter report-only policy can be deployed in production environments with no compatibility
  1.1349 +        risk and feedback can be collected from any violation reports received.  Once a site has
  1.1350 +        confidence that the policy is appropriate, they can promote the report-only policy to normal
  1.1351 +        blocking mode.</p>
  1.1352 +      </section><!-- Report-Only Mode -->
  1.1353 +
  1.1354 +      <section class="informative">
  1.1355 +        <h3>Other User-Agent Considerations</h3>
  1.1356 +        <p>This section contains miscellaneous items for consideration by user-agent
  1.1357 +        implementers.</p>
  1.1358 +
  1.1359 +        <h4>User Scripts</h4>
  1.1360 +        <p>Content Security Policy should not interfere with the operation of user-supplied scripts
  1.1361 +        such as third-party user-agent add-ons and JavaScript bookmarklets.</p>
  1.1362 +
  1.1363 +        <h4>Redirecting Content Loads</h4>
  1.1364 +        <p>For any protected document, when a request for a sub-document resource is redirected to
  1.1365 +        another location, whether temporary or permanent, all locations in the resource's redirect
  1.1366 +        chain, including the initial location and all subsequent redirected locations, must be
  1.1367 +        permitted by the protected document's security policy in order for the sub-document resource
  1.1368 +        to be allowed to load.  If any step in the redirect process violates the protected
  1.1369 +        document's security policy, the request should be terminated immediately and the load
  1.1370 +        canceled.</p>
  1.1371 +
  1.1372 +        <h4>Future Directives</h4>
  1.1373 +        <p>In order to support new policy directives in the future, user-agents must parse but
  1.1374 +        ignore unrecognized directives.  For this reason, this document specifies that user-agents
  1.1375 +        MUST skip over unrecognized directives but SHOULD report them on the error console.</p>
  1.1376 +      </section><!-- Other User-Agent Considerations -->
  1.1377 +
  1.1378 +    </section><!-- User-Agent Behavior -->
  1.1379 +
  1.1380 +    <section>
  1.1381 +      <h2>HTTP Server Behavior</h2>
  1.1382 +      <p>This section describes required behavior for conformant servers when emitting a Content
  1.1383 +      Security Policy.</p>
  1.1384 +
  1.1385 +      <section>
  1.1386 +        <h3>HTTP Header Placement</h3>
  1.1387 +        <p>The <a href="#x-content-security-policy-response-header">Content Security Policy HTTP
  1.1388 +        response header</a> MAY be present in the Message Headers section of a server's HTTP
  1.1389 +        response.</p>
  1.1390 +
  1.1391 +        <p>The <a href="#x-content-security-policy-response-header">Content Security Policy HTTP
  1.1392 +        response header</a> MUST NOT be present in the Trailer section of a server's HTTP response.
  1.1393 +        If a user-agent receives a Content Security Policy as an HTTP Trailer, it MUST NOT parse the
  1.1394 +        policy or attempt to enforce any restrictions on the rendered document.</p>
  1.1395 +
  1.1396 +        <p>HTTP Message Headers and Trailers are defined in the HTTP 1.1 standard. [[!HTTP11]]</p>
  1.1397 +      </section><!-- HTTP Header Placement -->
  1.1398 +
  1.1399 +    </section><!-- HTTP Server Behavior -->
  1.1400 +
  1.1401 +  </body>
  1.1402 +</html>