(below is my understanding of the decision) CSP tries to be robust against an attacker who is able to inject HTTP Headers. Thus the choice of intersecting multiple policies - thus an attacker can not reduce the security that a correct policy aims to provide. In report mode, there is a concern that CSP might leak sensitive data (cookies/capabilities). If both report and policy is allowed, then an attacker could reduce the security of an application by adding a (report-only) header which leaks information, which doesn't sit well with how the rest of CSP aims to work.
-devdatta On 12 March 2010 15:08, Lucas Adamski <lu...@mozilla.com> wrote: > Hmm, that's an interesting point. I believe the concern was around potential > for confusion when a mix of enforced and report-only policies was defined, so > the admin wouldn't forget to flip the switch from reporting to enforcing and > end up with a false sense of confidence. There are also some implementation > challenges with doing both; we'd need to track two separate set of policies, > one enforced and one reporting-only, but active simultaneously. The latter > is a solvable problem but we already got a lot of feedback over the perceived > complexity of the model. :) > > Nevertheless I think your use case for parallel research / testing makes a > lot of sense. > Lucas. > > On Mar 12, 2010, at 2:45 PM, Nick Kralevich wrote: > >> https://wiki.mozilla.org/Security/CSP/Spec#Report-Only_mode >> >> If both a X-Content-Security-Policy-Report-Only header and a >> X-Content-Security-Policy header are present in the same response, a warning >> is posted to the user agent's error console and any policy specified in >> X-Content-Security-Policy-Report-Only is ignored. The policy specified in >> X-Content-Security-Policy headers is enforced. >> >> >> Why is this? This seems like an unnecessary burden which prevents groups >> from tightening their security policies over time. >> >> For example, here at Google, I'm interested in helping resolve some of our >> Mixed Content warnings, so I might run the following header on all Google >> HTTPS sites: >> >> X-Content-Security-Policy-Report-Only: allow https://*:443; options >> inline_script eval-script; report-uri /someUri >> >> This will allow me to collect information on all the mixed-content >> violations which may occur. >> >> However, in the future, a different group may decide that they want to >> enforce a tighter policy, and may add the header: >> >> X-Content-Security-Policy: [something else] >> >> All of a sudden, two reasonable changes by two different people will result >> in a user visible error, and will suppress my ability to collect information >> about mixed-content errors. >> >> To me, it seems valuable to support both X-Content-Security-Policy >> and X-Content-Security-Policy-Report-Only, as it allows sites to test new >> restrictions without disrupting their current restrictions. >> >> -- Nick >> _______________________________________________ >> dev-security mailing list >> dev-security@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security > > _______________________________________________ > dev-security mailing list > dev-security@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
