- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Mon, 30 Apr 2012 12:15:11 -0700
- To: Adam Barth <w3c@adambarth.com>
- CC: Michal Zalewski <lcamtuf@coredump.cx>, public-webappsec@w3.org
On 2/3/12 1:08 AM, Adam Barth wrote: > On Thu, Feb 2, 2012 at 7:05 PM, Michal Zalewski wrote: >>> We dropped strict Content-Type matching because it makes it >>> significantly harder for folks to deploy CSP. >> >> This seems to be dwarfed by the other constraints of CSP (no >> inline scripts and stylesheets). There are many sites that do >> return user-controlled text or CSV documents (definitely >> several dozen examples on www.google.com), so this seems like a >> real problem, and I would recommend strict MIME checking. > > This difference is that these things are often controlled by > different folks. Web developers can often re-work their code to > avoid inline scripts, but MIME types are controlled by server > operators. That's part of the reason why the platform has been > moving away from strict MIME types, e.g., for AppCache manifests. > It's certainly inelegant and unfortunate, but it's the consistent > feedback we've gotten. We could do what we've done for inline-scripts: have a hard-line default policy with an option to disable. Failing that I'd like an option for sites to opt-in to stricter checking because we've seen plausible real-world "CSP bypasses" that can't always be blamed on the site author doing stupid things (E4X doesn't help -- die die die!). I propose script-src: 'any-type' to disable MIME-type checking, otherwise you're limited to a small whitelist such as application/javascript and application/json, maybe text/javascript if there's still a lot of that out there. Defaulting to strict would be safer for site authors who don't have time to become experts on every technical measure available to them, but an opt-in 'strict-type' keyword for the script-src directive would be better than nothing. -Dan Veditz
Received on Monday, 30 April 2012 19:15:56 UTC