- From: Adam Barth <w3c@adambarth.com>
- Date: Fri, 18 Feb 2011 21:00:15 -0800
- To: Daniel Veditz <dveditz@mozilla.com>
- Cc: public-web-security@w3.org
On Fri, Feb 18, 2011 at 8:46 PM, Daniel Veditz <dveditz@mozilla.com> wrote: > On 2/18/11 6:09 PM, Adam Barth wrote: >> In the Mozilla CSP spec, the presence of any Content-Security-Policy >> at all triggers blocking of JavaScript URL. > > Because it's a form of inline-script, and inline-scripts are blocked > by the mere presence of CSP. Like inline-scripts, however, not > everyone is ready to give them up so we added a hack^H^H^H^Hoverride > that lets people turn them back on. The "script-src" directive isn't > the best place for them because people rarely write "<script > src=javascript:code>". Most often they appear as links, which aren't > otherwise covered by the current CSP proposal. > > Maybe that argues that the javascript: override ought to be in the > "options" directive alongside inline-scripts. > > Like inline-scripts we wanted the presence of a CSP to opt-in to a > more rigorous web regime that outlawed such things > >> IMHO, the empty CSP policy (e.g., "") shouldn't have any effects. > > At what point do you disable inline-scripts then? If inline-scripts > aren't disabled by default there isn't a whole lot of point to CSP > in my opinion. I'm suggesting that we trigger disabling inline-scripts and JavaScript URLs on the presence of script-src (regardless of the value of the script-src directive) or of another directive (e.g., default-src) that implies script-src. Adam
Received on Saturday, 19 February 2011 05:01:22 UTC