- From: Dmitry Polyakov <dpolyakov@google.com>
- Date: Mon, 11 Aug 2014 14:14:18 -0700
- To: public-webappsec@w3.org
- Cc: mkwst@google.com
Hi, I’m a developer working on an implementation and deployment of Content Security Policy for YouTube web clients. Recently, I faced a problem with CSP, so let me describe my use case before diving in further. On YouTube.com we mostly deliver page content using a framework that allows us to update the page in chunks via XHRs. That includes navigating between “pages”. We only load content and resources that need to be updated and preserve everything else to improve latency. We call this structured page fragments, or “spf”. (The framework itself is available here https://github.com/youtube/spfjs) That means that whenever we serve the first spf-enabled page to a client, in order to define content security policy, we need to include _the entire_ list of all the resources YouTube.com pages could utilize, connect to, iframe, embed and so on. With the current infrastructure that we have in place, and our extensive integrations, that becomes a _really_ long list. I believe a large amount of web sites, especially high-traffic ones, are adopting this “web application" model, in which new content is mostly fetched via XHRs as opposed to loading new pages. Given that, it seems to me that there should be a way to refresh a delivered policy on a given page dynamically (i.e. without reloading that page). By "refreshing" I mean removing the enforced policy(ies) and enabling a new one(s), as opposed to strengthening enforced policies (with the use of meta elements for example). For example, it could be in a form of another directive, refresh-uri: uri-reference that would allow clients to issue requests to refresh-uri (via XHR or adding/updating a corresponding meta element(s), or making a browser send a request every time history is updated by the current document, or something else) that will return a new policy to enforce (i.e. Content-Security-Policy and/or Content-Security-Policy-Report-Only headers) and a 204 status. I’m not sure about security implications here. The obviously unclear thing would be retaining nonces (or updating them somehow). Another thing that would help reducing the policy indirectly is adding nonces or something like nonces to other directives (maybe hashes too). In this case nonces would serve a bit different purpose than allowing unsafe-inline execution. Unfortunately, I don’t know of prior discussions on these topics, so maybe there were already some clever solutions proposed. Please let me know what do you think. Dmitry.
Received on Tuesday, 12 August 2014 08:00:30 UTC