- From: Jonathan Kingston <jonathan@jooped.co.uk>
- Date: Sun, 22 Mar 2015 16:50:52 +0000
- To: public-webappsec@w3.org
- Message-ID: <CA+EVJMULW+XhQW_CH_Zd6MdFWMcOnbpVkA6J9p48MYX7PRtKyg@mail.gmail.com>
It may now make sense to discuss again about having an external policy file. So instead of the following headers: Content-Security-Policy-Pin: max-age: 10886400; includeSubDomains; default-src https:; form-action 'none'; frame-ancestors 'none'; referrer no-referrer; report-uri /csp-endpoint/pinned Content-Security-Policy: script-src https://application1.cdn.com; style-src https://application1.cdn.com; connect-src 'self'; form-action 'self' There could be: Content-Security-Policy-file: policy: '/policy.csp'; identity: 'ni:///sha-256;asijfiqu4t12...woeji3W?ct=application/csp' And in '/policy.csp': Content-Security-Policy-Pin: max-age: 10886400; includeSubDomains; default-src https:; form-action 'none'; frame-ancestors 'none'; referrer no-referrer; report-uri /csp-endpoint/pinned Content-Security-Policy: script-src https://application1.cdn.com; style-src https://application1.cdn.com; connect-src 'self'; form-action 'self' Where the first request to a site would need to do a synchronous request to the policy file before loading other content (or potentially allow other requests to be made but not parsed or executed until the CSP is loaded). Due to most policies being the same for the whole domain and policies are getting more features the file might allow for far more granular directives. The integrity would ensure that the CSP would only be trusted over a previous set of rules so long as the policy file matches the integrity. If the policy failed to match I would suggest using the previous set of rules.
Received on Sunday, 22 March 2015 16:51:21 UTC