Checking in Brad's initial draft
authorDavid Lin-Shung Huang <linshung.huang@sv.cmu.edu>
Sun, 10 Jun 2012 16:42:02 -0700
changeset 0 6834f5e73e7b
child 1 2f0839da87bd
Checking in Brad's initial draft
user-interface-safety.html
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/user-interface-safety.html	Sun Jun 10 16:42:02 2012 -0700
@@ -0,0 +1,593 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>User Interface Safety Directives for Content Security Policy</title>
+    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
+    <!--
+      === NOTA BENE ===
+      For the three scripts below, if your spec resides on dev.w3 you can check them
+      out in the same tree and use relative links so that they'll work offline,
+     -->
+    <script src='js/respec.js' class='remove'></script>
+    <script class='remove'>
+      var respecConfig = {
+          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+          // Member-SUBM
+          specStatus:           "ED",
+
+          // the specification's short name, as in http://www.w3.org/TR/short-name/
+          shortName:            "User Interface Safety",
+
+          // if your specification has a subtitle that goes below the main
+          // formal title, define it here
+          // subtitle   :  "an excellent document",
+
+          // if you wish the publication date to be other than today, set this
+          // publishDate:  "2009-08-06",
+
+          // if the specification's copyright date is a range of years, specify
+          // the start date here:
+          copyrightStart: "2012",
+
+          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+          // and its maturity status
+          // previousPublishDate:  "1977-03-15",
+          // previousMaturity:  "WD",
+
+          // if there a publicly available Editor's Draft, this is the link
+          //edDraftURI:           "http://dvcs.w3.org/hg/uisafety/raw-file/tip/uisafety.dev.html",
+
+          // if this is a LCWD, uncomment and set the end of its review period
+          // lcEnd: "2009-08-05",
+
+          // if you want to have extra CSS, append them to this list
+          // it is recommended that the respec.css stylesheet be kept
+          extraCSS:             ["css/respec.css"],
+
+          // editors, add as many as you like
+          // only "name" is required
+          editors:  [
+              { name: "Giorgio Maone", url: "mailto:g.maone@informaction.com",
+                company: "Invited Expert", companyURL: "" },
+              { name: "David Lin-Shung Huang", url: "mailto:linshung.huang@sv.cmu.edu",
+                company: "Carnegie-Mellon University", companyURL: "http://sv.cmu.edu/" },
+	      { name: "Brad Hill", url: "mailto:bhill@paypal-inc.com",
+		company: "PayPal Inc.", copanyURL: "https://www.paypal.com/" },
+          ],
+
+          // authors, add as many as you like. 
+          // This is optional, uncomment if you have authors as well as editors.
+          // only "name" is required. Same format as editors.
+
+          //authors:  [
+          //    { name: "Your Name", url: "http://example.org/",
+          //      company: "Your Company", companyURL: "http://example.com/" },
+          //],
+
+          // name of the WG
+          wg:           "Web Application Security Working Group",
+
+          // URI of the public WG page
+          wgURI:        "http://www.w3.org/2011/webappsec/",
+
+          // name (with the @w3c.org) of the public mailing to which comments are due
+          wgPublicList: "public-webappsec",
+
+
+          // URI of the patent status for this WG, for Rec-track documents
+          // !!!! IMPORTANT !!!!
+          // This is important for Rec-track documents, do not copy a patent URI from a random
+          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+          // Team Contact.
+          wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/49309/status"
+      };
+    </script>
+  </head>
+  <body>
+    <section id="abstract">
+    <p>This document defines a directive for the Content Security Policy 1.0 mechanism
+      to allow Web application developers to declare a set of protections for a web resource 
+      to help prevent malicious obscuring or re-contextualizing of the resource's user interface
+      when it is displayed in an embedded context.
+
+      The document also defines a set of heuristics for Web user agents to implement these
+      protections and a reporting mechanism for when they are triggered.
+      </p>
+    </section>
+
+    <section id="sotd">
+    <p>Portions of the technology described in this document were developed as part of the
+    X-Frame-Options header.</p>
+
+    <p>Portions of the technology described in this document were developed and
+    implemented in the ClearClick module of the Mozilla Firefox add-on NoScript.</p>
+
+    <p>This document uses the syntax and mechanism of the Content Security Policy 1.0
+    and defines a new directive to convey anti-clickjacking policy.</p>
+
+      <p>In addition to the documents in the W3C Web Application Security
+      working group, the work on this document is also informed by the work of
+      the <a href="http://tools.ietf.org/wg/websec/">IETF websec working
+      group</a>, particularly that working group's requirements document:
+      <a href="http://tools.ietf.org/id/draft-hodges-websec-framework-reqs">draft-hodges-websec-framework-reqs</a>.
+    </section>
+
+    <section class="informative">
+      <h2>Introduction</h2>
+
+      <p>This document defines new directives for Content Security Policy 1.0
+      to allow applications to mitigate some of the risks of User Interface 
+      Redressing vulnerabilities that can lead to fraud.<p>
+
+      <p>Content Security Policy is a declarative policy that lets the authors
+      (or server administrators) of a web application restrict from where
+      an application can load resources. The intent and implementation of
+      the directive defined in this document differs in that respect from
+      other directives defined in CSP 1.0.  A user agent may implement
+      the directives of CSP 1.0 independently from the directives in this
+      specification, but the policy conveyance mechanism for the directives
+      in this specicification is described in CSP 1.0.  Application authors
+      should transmit the directives in this specification as part of a single,
+      complete Content Security Policy, as indicated by that specification.</p>
+
+      <p>Content Security Policy (CSP) is not intended as a first line of
+      defense against content injection vulnerabilities. Instead, CSP is best
+      used as defense-in-depth, to reduce the harm caused by content injection
+      attacks.</p>
+
+      <p>The anti-clickjacking directive can often be applied to existing 
+      applications with few or no changes, but the hueristic hints supplied
+      by the policy may require considerable experimental fine-tuning to
+      achieve an acceptable error rate.</p>
+
+      <p>This specification obsoletes X-Frame-Options.
+      Resources may supply an X-Frame-Options header in addition to
+      a Content-Security-Policy header to indicate policy to user agents
+      that do not implement the directives in this specification.  A user
+      agent that understands the directives in this document should ignore
+      the X-Frame-Options header, when present, if User Interface Safety directives
+      are also present in a Content-Security-Policy header. This is to allow 
+      resources to only be embedded if the mechanisms described in
+      this specification are enforced, and more restrictive X-Frame-Options
+      policies applied otherwise. 
+    </section>
+
+    <section id="conformance">
+      <p>Requirements phrased in the imperative as part of algorithms (such as
+      "strip any leading space characters" or "return false and abort these
+      steps") are to be interpreted with the meaning of the key word ("MUST",
+      "SHOULD", "MAY", etc) used in introducing the algorithm.</p>
+
+      <p>A conformant user agent is one that implements all the requirements
+      listed in this specification that are applicable to user-agents.</p>
+
+      <p>A conformant server is one that implements all the requirements
+      listed in this specification that are applicable to servers.</p>
+
+      <section>
+        <h3>Terminology</h3>
+
+        <p>This section defines several terms used throughout the document.</p>
+
+        <p>The term <dfn>security policy</dfn>, or
+        simply <dfn>policy</dfn>, for the purposes of this
+        specification refers to either:
+          <ol>
+            <li>a set of security preferences for restricting the behavior of
+            content within a given resource, or</li>
+            <li>a fragment of text that codifies these preferences.</li>
+          </ol>
+        </p>
+
+        <p>The security policies defined by this document are applied by a
+        user agent on a <em>per-resource representation basis</em>.
+        Specifically, when a user agent receives a policy along with the
+        representation of a given resource, that policy applies to <em>that
+        resource representation only</em>. This document often referes to
+        that resource representation as the <dfn>protected resource</dfn>.
+
+        <p>A server transmits its security policy for a particular resource as
+        a collection of <dfn>directives</dfn>, such as <code>default-src
+        'self'</code>, each of which controls a specific set of privileges for
+        a document rendered by the user agent. More details are provided in the
+        <a href="#directives">directives</a> section.</p>
+
+        <p>A directive consists of a <dfn>directive name</dfn>, which
+        indicates the privileges controlled by the directive, and a
+        <dfn>directive value</dfn>, which specifies the restrictions the
+        policy imposes on those privileges.</p>
+
+        <p>The term <dfn>origin</dfn> is defined in the Origin specification.
+        [<em><a href="http://tools.ietf.org/html/draft-ietf-websec-origin">ORIGIN</a></em>]</p>
+
+        <p>The term <dfn>URI</dfn> is defined in the URI specification.  [[!URI]]</p>
+
+        <p>The <code>&lt;script&gt;</code>, <code>&lt;object&gt;</code>, <code>&lt;embed&gt;</code>,
+        <code>&lt;img&gt;</code>, <code>&lt;video&gt;</code>, <code>&lt;audio&gt;</code>,
+        <code>&lt;link&gt;</code>, <code>&lt;frame&gt;</code> and <code>&lt;iframe&gt;</code>
+        elements are defined in the HTML5 standard. [[!HTML5]].</p>
+
+        <p>The <code>&lt;applet&gt;</code> element is defined in the HTML 4.01 standard. [[!HTML401]].</p>
+
+        <p>The <code>@font-face</code> CSS rule is defined in the CSS Fonts Module Level 3 standard.
+        [[!CSS3FONT]]</p>
+
+        <p>The <code>XMLHttpRequest</code> object is defined in the <code>XMLHttpRequest</code>
+        standard. [[!XMLHTTPREQUEST]]</p>
+
+        <p>The <code>WebSocket</code> object is defined in the <code>WebSocket</code>
+        standard. [<em><a href="http://dev.w3.org/html5/websockets/">WEBSOCKET</a></em>].</p>
+
+        <p>The <code>EventSource</code> object is defined in the <code>EventSource</code>
+        standard. [<em><a href="http://dev.w3.org/html5/eventsource/">EVENTSOURCE</a></em>].</p>
+
+        <p>The Augmented Backus-Naur Form (ABNF) notation used in this
+        document is specified in RFC 5234. [[!ABNF]]</p>
+
+        <p>The following core rules are included by reference, as defined in
+        [<em><a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">ABNF Appendix B.1</a></em>]:
+        <code>ALPHA</code> (letters), <code>DIGIT</code> (decimal
+        0-9), <code>WSP</code> (white space) and <code>VCHAR</code> (printing
+        characters).</p>
+
+        <p>The OWS rule is used where zero or more linear whitespace octets
+        might appear.  OWS SHOULD either not be produced or be produced as a
+        single SP.  Multiple OWS octets that occur within field-content SHOULD
+        either be replaced with a single SP or transformed to all SP octets
+        (each octet other than SP replaced with SP) before interpreting the
+        field value or forwarding the message downstream.<p>
+
+<pre>
+OWS            = *( SP / HTAB / obs-fold )
+               ; "optional" whitespace
+obs-fold       = CRLF ( SP / HTAB )
+               ; obsolete line folding
+</pre>
+
+      </section>
+    </section>
+
+    <section>
+      <h2 id="sec-directives">Directives</h2>
+
+      <p>This section describes the content security policy directives
+      introduced in this specification.</p>
+
+      <section>
+        <h3><code>embed-ancestors</code></h3>
+
+        <p><em>TODO:</em> Coordinate with the <a
+        href="http://tools.ietf.org/wg/websec/">IETF websec Working
+        Group</a>.</p>
+
+	<p>The <code>embed-options</code> directive indicates whether the
+	user-agent should embed the resource using a <code>frame</code>,
+	<code>iframe</code>, <code>object</code> or <code>embed</code> tag,
+	or equivalent functionality in non-HTML resources.
+	Resources can use this to avoid many UI Redressing attacks by ensuring 
+	they are not embedded into other sites.	
+	This directive replicates some of the functionality of the 
+	<code>X-Frame-Options</code> header. The syntax for the name and 
+	value of the directive are described by the following ABNF grammar:</p>
+
+<pre>
+directive-name    = "embed-ancestors"
+directive-value   = source-list
+</pre>
+
+	<p>Unlike policies defined in Content Security Policy 1.0, the
+	<code>embed-ancestors</code> directives is not subject to the 
+	<code>default-src</code> directive.  If this directive is not 
+	explicitly stated in the policy its value is assumed to be <code>"*"</code>.  
+
+	<p>If <code>'deny'</code> is present in the source-list, the resource
+	cannot be displayed in an embedded context, regardless of the origin attempting
+	to do so, and all other members of the source-list are ignored.  This
+	provides functionality equivalent to the <code>DENY</code> value of
+	the <code>X-Frame-Options header.</code></p>
+
+	<p>If <code>'deny'</code> is not present the source-list indicates
+	which origins are valid <strong>ancestors</strong> for the resource.
+	An ancestor is any resource between the protected resource and
+	the top of the window frame tree; for example, if A embeds B which 
+	embeds C, both A and B are ancestors of C. If A embeds both B and C,
+	B is not an ancestor of C, but A still is.</p>
+
+	<p>The <code>'self'</code> source indicates that content of the same-origin
+	as the protected resource may embed it.	This provides functionality
+	equivalent to the <code>SAMEORIGIN</code> value of the <code>
+	X-Frame-Options</code> header.</p>
+
+
+      </section>
+
+      <section>
+        <h3><code>click-protection</code></h3>
+
+	<p>The <code>click-protection</code> directive, if present,
+        instructs the user agent to apply the heuistic clickjacking
+	protections described in <a href="">Section XXX</a> to click
+	and drag-and-drop events delivered before they are delivered
+	to the resouce in an embedded context.
+	</p>
+
+	<p>ISSUE: Need some optimization language here. 
+	e.g. If the resource is not embedded (it is topmost in the
+	user agent rendering context) or if all <strong>ancestors</strong>
+	are <strong>same origin</strong> this token may be ignored.  
+	<em>TODO: </em>this still allows attacks with multiple windows in 
+	environments where that is possible (traditional desktop OS) but
+	to defend against this the user-visible screenshot would have to 
+	be defined in terms of the OS, not the user agent.
+
+<pre>
+directive-name    = "click-protection"
+directive-value   = "block" / "deliver"  
+</pre>
+
+	<p>A value of <code>block</code> indicates the user agent should
+	not deliver the event to the resource if the click protection
+	heuristic is triggered.</p>
+
+	<p>A value of <code>deliver</code> indicates the user agent should
+	deliver the event to the resource, even if the click protection
+	heuristic is triggered.</p>
+
+	<p>If a report-uri is present, triggering of the click protection
+	heuristic MUST always generate a report, whether the event is
+	delivered or not.</p>
+
+	<p>User agents SHOULD NOT prompt the user when the click protection
+	heuristic is triggered.</p>
+
+	<p>ISSUE: is it worth having a "deliver" option, or should this
+	just always be part of a report-only policy?</p>
+
+      </section>
+      <section>
+        <h3><code>click-protection-hints</code></h3>
+
+	<p>The <code>click-protection-hints</code> directive allows a
+        resource to provide hints to the <code>click-protection</code>
+	heuristics for greater accuracy.	
+
+<pre>
+directive-name    = "click-protection-hints"
+directive-value   = ["tolerance=" num-val] ["viewport-height=" num-val] ["viewport-width=" num-val] ["ui-delay=" num-val] 
+</pre>
+
+	<p>If the policy does not contain  explicit <code>click-protection-hints</code>
+	or any of the optional values are absent, the user agent should apply default
+	values as described in <a href="">Section XXX</a>. A user agent MAY ignore
+	any or all values in <code>click-protection-hints</code>.</p>
+	
+	<p><code>tolerance</code> is a numeric value from 0-99 that defines the
+	threshold at which the screenshot comparision procedure triggers the
+	click protection heuristic.  A value of 0 indicates that no difference
+        between the two images is permitted.  A value of 99 provides little
+	to no practical protection.	
+        </p>
+
+	<p><code>viewport-height</code> is a numeric value that defines the height of
+	the viewport to be used for performing the screenshot comparision.<p>
+
+	<p><code>viewport-width</code> is a numeric value that defines the width of
+	the viewport to be used for performing the screenshot comparision.<p>
+
+	<p><code>ui-delay</code> is a numeric value that specifies the delay time, in 
+	milliseconds, used in the click protection heuristic.</p>
+
+	<p><code>protected-id</code> <em>???</em> does it make sense to allow protections to apply
+	to a named element in the DOM, instead of a viewport window?</p>
+
+
+      </section>
+
+      <section>
+      <h2>Click Protection Heuristic</h2>
+
+      <section class="informative">
+      <p>This section is non-normative. The algorithm described here can be implemented mostly in terms of
+      HTML5 constructs, but requries the ability to monitor and intercept actions in the rendering of a
+      resource and delivery of events to that resource.  User agents may apply equivalent protections
+      using means more optimized for their implementation details, may ignore recommendations where
+      the browsing environment eliminates certain classes of attack, (e.g. cursor sanity check in a
+      touch-only environment) or may implement some features in terms of the underlying operating system
+      or platform rather than directly in the user agent.</p>
+
+      <h3>Algorithm Description</h3>
+
+      <ol>
+	      <li><strong>Listener registration</strong> - Register a "global" capturing event listener
+	      for mouse button, tapping, keyboard, drag &amp; drop and focus events, which must be 
+	      guaranteed to run before any other event handler of the same kind and therefore be able 
+	      to prevent any event from being handled by the content, if needed.
+
+	      <em>CBC: in order to guarantee the "first to process' event listener requirement 
+		      and reduce registration overhead, ClearClick adds its listener to the 
+		      Mozilla-specific DocShell object which is the immediate container of the 
+		      topmost DOM window per any given tab. A crossbrowser approach likely to 
+		      work is registering the listener on the topmost DOM window itself before 
+		      any script has a chance to run.</em>
+		</li>
+
+		<li><strong>Fast-track bypass</strong> - Whenever the listener is called, 
+		check whether the event target or its owner document are flagged as "unlocked".
+		If either is, return early.
+		
+		<em>CBC: ClearClick uses an expando property to flag DOM nodes and windows, relying on a
+feature of Mozilla's chrome-exposed DOM wrappers which prevents content from seeing or
+tamper with expando properties set by privileged code. Other browsers may require
+different procedures to safely annotate documents and other DOM nodes. Furthermore, this
+and most of the remaining steps assume our listener can examine and manipulate any DOM
+node or window independently from its origin, bypassing SOP. This privilege should be
+granted by the listener having being registered by privileged (browser extension) code.</em>
+
+		</li>
+
+		<li><strong>Parent chain check</strong> - Check whether the event target is either
+		a child of a nested document or a plugin content element (EMBED, APPLET or OBJECT). 
+		If it is not, or it is an embedded document belonging to a same-site parent chain
+		(i.e. it and all its parents are from the same origin), flag the document as 
+		"unlocked" and return. Notice that the original Clickjacking demo by Hansen &amp; 
+		Grossman worked despite the Flash content being served same-site: since plugins 
+		may follow type-specific origin policies, we never return early at
+		this stage when interacting with plugin content, even if embedded same-site.</li>
+
+	
+		<li><strong>Rapid fire check</strong> - Check whether the previous event we had
+		observed was the same type on a document from a different origin, happened within
+		the past 800ms (quarantine time). If it was, we assume a "Rapid fire" attack 
+		(e.g. the user has been tricked into repeatedly click on the same or a predictable
+		location in a fast succession while the document gets changed under his mouse pointer)
+		: halve the quarantine time and go to step 8. If next interaction happens with a 
+		different document, the quarantine time will be reset.</li>
+
+		<li><strong>Cursor sanity check</strong> - By querying computed-style with the ":hover"
+		pseudo-class on the element (if the target is plugin content) or on the host frame 
+		element and its ancestors (if the target is a nested document), check whether the 
+		cursor has been hidden or changed to an possibly attacker-provided bitmap: if it has, 
+		go to step 7. This provides protection against "Phantom cursor" attacks, also known 
+		as "Cursorjacking".
+
+		<li><strong>Obstruction check</strong> - By using an offscreen HTML 5 canvas element, 
+		we take two reasonably sized (300x200 on average, but growing or shrinking depending 
+		on document's inherent size and viewport constraints and hints provided by the
+		<code>viewport-height</code> and <code>viewport-width</code> properties of <code>
+		click-protection-hints</code>) screenshots of the region centered around the DOM 
+		element which is about to receive the event: one from its owner document's 
+		"point of view" (unobstructed by definition), 
+		the other from the topmost window's. In the plugin content case, we ensure the former
+		"screenshot" contains the element itself only. If the number of the pixels which are 
+		different between the screenshots don't exceed a certain configurable tolerance rate 
+		(default 18%, or as set by the <code>tolerance</code> property of 
+		<code>click-protection-hints</code>), return. Otherwise we tentatively assume the 
+		DOM element our user is interacting with has been obstructed or obscured by a 
+		UI Redressing attempt.  
+		
+		<em>CBC: the screenshots are taken by using the CanvasRenderingContext2D.drawWindow()
+method11, which is a Mozilla-proprietary extension of the HTML 5 Canvas API available to
+privileged code only, allowing the content of DOM windows to be drawn on a canvas
+surface exactly as rendered on the screen. The rest of this phase relies on cross-browser
+canvas features, instead, such as pixel grabbing and data URL serialization.</em>
+		</li>
+</ol>
+
+      </section>
+
+      </section>
+    <section>
+      <h2>Examples</h2>
+
+      <section class="informative">
+        <h3>Sample Policy Definitions</h3>
+
+        <p>This section provides some sample use cases and accompanying security policies.</p>
+
+        <p><strong>Example 1:</strong> A server wishes to load resources only
+        form its own origin:</p>
+
+        <pre>Content-Security-Policy: default-src 'self'</pre>
+
+        <p><strong>Example 2:</strong> An auction site wishes to load images
+        from any URI, plugin content from a list of trusted media providers
+        (including a content distribution network), and scripts only from a
+        server under its control hosting sanitized ECMAScript:</p>
+
+        <pre>Content-Security-Policy: default-src 'self'; img-src *;
+                         object-src media1.example.com media2.example.com *.cdn.example.com;
+                         script-src trustedscripts.example.com</pre>
+
+        <p><strong>Example 3:</strong> Online banking site wishes to ensure that all of the content
+        in its pages is loaded over TLS to prevent attackers from eavesdropping on insecure content
+        requests:</p>
+
+        <pre>Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval'</pre>
+      </section>
+
+      <section class="informative">
+        <h3>Sample Violation Report</h3>
+
+        <p>This section contains an example violation report the user agent
+        might sent to a server when the protected resource violations a sample
+        policy.</p>
+
+        <p>In the following example, a document from
+        <code>http://example.org/page.html</code> was rendered with the
+        following CSP policy:</p>
+
+<pre>default-src 'self'; report-uri http://example.org/csp-report.cgi</pre>
+
+        <p>The document loaded an image from
+        <code>http://evil.example.com/image.png</code>, violating the
+        policy.</p>
+
+        <pre>{
+  "csp-report": {
+    "document-uri": "http://example.org/page.html",
+    "referrer": "http://evil.example.com/haxor.html",
+    "blocked-uri": "http://evil.example.com/image.png",
+    "violated-directive": "default-src 'self'",
+    "original-policy": "default-src 'self'; report-uri http://example.org/csp-report.cgi"
+  }
+}</pre>
+
+      </section>
+    </section>
+    <section>
+      <h2>Security Considerations</h2>
+      <section>
+      </section>
+    </section>
+    <section>
+      <h2>Implementation Considerations</h2>
+
+      <p><em>XXX TODO</em></p>
+	
+    </section>
+    <section>
+    	<h2>Implementation Considerations for Resource Authors</h2>
+	<p><em>XXX TODO</em> suggestions on back-end anti-fraud here and use of unique, per-transaction report-uris with information about 
+	targets encoded, and use of report-only to collect possible fraud data without blocking transactions.
+	</p>
+    <section>
+      <h2>IANA Considerations</h2>
+
+      <p>The permanent message header field registry (see [<a
+      href="http://tools.ietf.org/html/rfc3864">RFC3864</a>]) should be updated
+      with the following registrations:</p>
+
+      <section>
+        <h2>Content-Security-Policy</h2>
+
+        <p>Header field name: Content-Security-Policy</p>
+
+        <p>Applicable protocol: http</p>
+
+        <p>Status: standard</p>
+
+        <p>Author/Change controller: W3C</p>
+
+        <p>Specification document: this specification (See <a
+        href="#content-security-policy-header-field"><code>Content-Security-Policy</code>
+        Header Field</a>)</p>
+      </section>
+
+      <section>
+        <h2>Content-Security-Policy-Report-Only</h2>
+
+        <p>Header field name: Content-Security-Policy-Report-Only</p>
+
+        <p>Applicable protocol: http</p>
+
+        <p>Status: standard</p>
+
+        <p>Author/Change controller: W3C</p>
+
+        <p>Specification document: this specification (See <a
+        href="#content-security-policy-report-only-header-field"><code>Content-Security-Policy-Report-Only</code>
+        Header Field</a>)</p>
+      </section>
+    </section>
+  </body>
+</html>