CSP 1.1: Add non-normative examples of enforcing multiple policies.
authorMike West <mkwst@google.com>
Tue, 29 Jan 2013 22:37:12 +0100
changeset 181748bf7da3690
parent 180 e0270baace3d
child 182 3affa0c38706
CSP 1.1: Add non-normative examples of enforcing multiple policies.

The question of multiple-policy enforcement came up in December twice on the
list. The proper handling is technically clear in section 3.1.1/3.1.2, but could
be much clearer to developers with an example.

This patch adds section 3.1.4 with an example to attempt to address the deficit
of clarity.

This should close ACTION-106.
csp-specification.dev.html
     1.1 --- a/csp-specification.dev.html	Wed Dec 19 01:33:33 2012 +0100
     1.2 +++ b/csp-specification.dev.html	Tue Jan 29 22:37:12 2013 +0100
     1.3 @@ -306,6 +306,36 @@
     1.4                still useful in light of the above mitigations?)</li>
     1.5            </ul>
     1.6          </section>
     1.7 +        <section class="informative">
     1.8 +          <h4>Enforcing multiple policies.</h4>
     1.9 +          <p>The above sections note that when multiple policies are present,
    1.10 +          each must be enforced or reported, according to its type. An example
    1.11 +          will help clarify how that ought to work in practice. The behavior of
    1.12 +          an <code>XMLHttpRequest</code> might seem unclear given a site
    1.13 +          that, for whatever reason, delivered the following HTTP headers:</p>
    1.14 +          <pre>
    1.15 +Content-Security-Policy: default-src 'self' http://example.com http://example.net;
    1.16 +                         connect-src 'none';
    1.17 +Content-Security-Policy: connect-src http://example.com/;
    1.18 +                         script-src http://example.com/
    1.19 +          </pre>
    1.20 +          <p>Is a connection to <code>example.com</code> allowed or not? The
    1.21 +          short answer is that the connection is not allowed. Enforcing both
    1.22 +          policies means that a potential connection would have to pass through
    1.23 +          both unscathed. Even though the second policy would allow this
    1.24 +          connection, the first policy contains <code>connect-src 'none'</code>,
    1.25 +          so its enforcement blocks the connection. The impact is that adding
    1.26 +          additional policies to the list of policies to enforce can only
    1.27 +          further restrict the capabilities of the protected resource.</p>
    1.28 +          <p>To demonstrate that further, consider a script tag on this page.
    1.29 +          The first policy would lock scripts down to <code>'self'</code>,
    1.30 +          <code>http://example.com</code> and <code>http://example.net</code>
    1.31 +          via the <code>default-src</code> directive. The second, however, would
    1.32 +          only allow script from <code>http://example.com/</code>. Script will
    1.33 +          only load if it meets both policy's criteria: in this case, the only
    1.34 +          origin that can match is <code>http://example.com</code>, as both
    1.35 +          policies allow it.</p>
    1.36 +        </section>
    1.37        </section>
    1.38  
    1.39        <section>