Update Implementation Considerations based on face-to-face discussion.
authorAdam Barth <w3c@adambarth.com>
Sun, 06 May 2012 23:24:07 -0700
changeset 99eea1c214cc85
parent 98 eeb1f359567c
child 100 96603653094a
Update Implementation Considerations based on face-to-face discussion.
csp-specification.dev.html
     1.1 --- a/csp-specification.dev.html	Fri Apr 13 16:27:44 2012 -0700
     1.2 +++ b/csp-specification.dev.html	Sun May 06 23:24:07 2012 -0700
     1.3 @@ -1173,29 +1173,53 @@
     1.4      </section>
     1.5      <section>
     1.6        <h2>Implementation Considerations</h2>
     1.7 -      <section>
     1.8 -        <h3>Servers</h3>
     1.9  
    1.10 -        <p>Some servers might wish to combine multiple Content Security
    1.11 -        Policies (e.g., from multiple components in a single document).
    1.12 -        Servers SHOULD use the following algorithm to combine policies:</p>
    1.13 +      <p>The <code>Content-Security-Policy</code> header is an end-to-end
    1.14 +      header.  It is processed and enforced at the client and, therefore,
    1.15 +      SHOULD NOT be modified or removed by proxies or other intermediaries not
    1.16 +      in the same administrative domain as the resource.</p>
    1.17  
    1.18 -        <ol>
    1.19 -          <li>TODO</li>
    1.20 -        </ol>
    1.21 +      <p>The originating administrative domain for a resource might wish to
    1.22 +      apply a <code>Content-Security-Policy</code> header outside of the
    1.23 +      immediate context of an application.  For example, a large organization
    1.24 +      might have many resources and applications managed by different
    1.25 +      individuals or teams but all subject to a uniform organizational
    1.26 +      standard. In such situations, a <code>Content-Security-Policy</code>
    1.27 +      header might be added or combined with an existing one at a network-edge
    1.28 +      security gateway device or web application firewall.  When using the
    1.29 +      <code>Content-Security-Policy</code> header in this way, administrators
    1.30 +      ought to remember that the user agent will enforce only the first policy
    1.31 +      statement it receives.  To enforce multiple policies, the administrator
    1.32 +      MUST combine the policy into a single header.  An administrator might
    1.33 +      wish to use different combination algorithms depending on his or her
    1.34 +      intended semantics.</p>
    1.35  
    1.36 -        <h3>Internet Service Providers</h3>
    1.37 +      <p>One sensible policy combination algorithm is to start by allowing a
    1.38 +      default set of sources and then letting individual upstream resource
    1.39 +      owners expand the set of allowed sources by including additional origins.
    1.40 +      In this approach, the resultant policy is the union of all allowed
    1.41 +      origins in the input policies.</p>
    1.42  
    1.43 -        <p>Some Internet service providers manipulate resources as they travel
    1.44 -        across their networks [TODO: Citation needed]. It's possible that these
    1.45 -        manipulations can cause a site to violate its Content Security Policy.</p>
    1.46 +      <p>Another sensible policy combination algorithm is to intersect the
    1.47 +      given policies.  This approach enforces that content comes from a certain
    1.48 +      whitelist of origins, for example, preventing developers from including
    1.49 +      third-party scripts or content in violation of organizational standards
    1.50 +      and practices.  In this approach, the combination algorithm forms the
    1.51 +      combined policy by removing disallowed hosts from the policies supplied
    1.52 +      by upstream resource owners.</p>
    1.53  
    1.54 -        <p>Internet server providers SHOULD NOT manipulate resources as they
    1.55 -        travel across their networks. If Internet Service Providers persist in
    1.56 -        manipulating these resources, servers SHOULD employ transport-layer
    1.57 -        security, such as HTTPS, to ensure the integrity of their site over
    1.58 -        hostile networks.</p>
    1.59 -      </section>
    1.60 +      <p>Interactions between the <code>default-src</code> and other directives
    1.61 +      SHOULD be given special consideration when combining policies.  If none
    1.62 +      of the policies contains a <code>default-src</code> directive, adding new
    1.63 +      src directives results in a more restrictive policy.  However, if one or
    1.64 +      more of the input policies contain a <code>default-src</code> directive,
    1.65 +      adding new src directives might result in a less restrictive policy, for
    1.66 +      example, if the more specific directive contains a more permissive set of
    1.67 +      allowed origins.</p>
    1.68 +
    1.69 +      <p>Using a more restrictive policy than the input policy authored by the
    1.70 +      resource owner might prevent the resource from rendering or operating as
    1.71 +      intended.</p>
    1.72      </section>
    1.73      <section>
    1.74        <h2>IANA Considerations</h2>