Security/CSP/Specification: Difference between revisions

When multiple instances of the <tt>X-Content-Security-Policy</tt> HTTP header are present in an HTTP response, the intersection of the policies is enforced; essentially, the browser enforces a policy that is more strict than both the policies specified in the multiple headers, but only strict enough to correspond to rules in all policies.  Any web request that satisfied ''all'' policies alone will be accepted by the new policy, but any request rejected by ''any of'' of the two policies will be rejected.  The intersection is calculated on a directive-by-directive basis (i.e., the intersection of the <tt>allow</tt> directive is taken and enforced as the <tt>allow</tt> part of the effective policy). Explicitly, for two policies:

If more than two instances of the <tt>X-Content-Security-Policy</tt> header are present in the response, the intersection is done digest-style: the first two policies are removed from the set of headers to digest, intersected, and the result is placed back in the set.  This continues until only one policy remains.  e.g.,

If two policy headers are present, one (P₁) may allow scripts from domains A, B and C.  The policy in the other header (P₂) may allow scripts from domains B, C and D.  The policy enforced (P_enforced) by the browser will allow scripts from domains B and C only (P_enforced = P₁ &cap; P₂).

 

 

Because the <tt>X-Content-Security-Policy</tt> header may appear multiple times in the response, it is possible they're crafted by different entities and may conflict.  A decision must be made about which policy to use, or whether to combine them or not.  Assuming there are two different policies present, there are five obvious ways to address this conflict:

 

#<b>Use the first header's policy.</b>

 

If multiple headers define policies with <tt>report-uri</tt> values, a single report is sent to each of the provided URIs.  If any <tt>report-uri</tt> values are the same, only one report for each violation is sent to that URI; essentially one report is sent to each distinct URI upon policy violation.

Report-duplication (or multiple reporting) is useful in the case where two different groups want to receive reports, but may not share access to the reports archive.  Take for instance a large web company that has a separate sysadmin staff (who are also in charge of security at some level) and project teams.  One project team may be interested in receiving reports about violations of their CSP, but are not interested in violations on other parts of the web site.  The sysadmin team wants to record all violations from all parts of the site into a massive archive.  The multiple reporting technique allows both entities to receive the reports they want without causing extra data-mining work on the part of the sysadmin team to isolate the reports that each project team may want.

Since HTTP headers and the entire request string are sent in the report, it is possible that, in case of compromise, a violation report could leak private information to an arbitrary URI.  To avoid any possible cross-domain cookie or authentication token transfer, <b>all reports must be sent to the same origin (scheme/host/port) that served the protected content</b>.

Two headers present conflicting policies, they are resolved through a straightforward process: first the policies are made explicit (see below), then they are intersected, and the resulting policy is enforced.  Through this process, the enforced policy will <i>never be more lenient</i> than either of the conflicting policies.

This refinement procedure is only followed if there are multiple instances of the <tt>X-Content-Security-Policy</tt> HTTP header present in the HTTP response.