Jean-Marc Desperrier wrote on 7/17/2009 2:26 AM: > Daniel Veditz wrote: >> CSP is designed so that mistakes of omission tend to break the site >> break. This won't introduce subtle bugs, rudimentary content testing >> will quickly reveal problems. > > But won't authors fail to understand how to solve the problem, and open > everything wide ? From experience, that's what happens with technologies > that are too complex.
If authors believe it's too complex, I would imagine they wouldn't implement it at all; but if they do configure it wide open, it's the equivalent of not using it -- the net result is identical, except perhaps Ian's suggestion that an uninformed author would mistakenly believe they were protected. An external validation tool could help authors understand what their CSP rules are actually allowing/preventing (maybe something similar to validator.w3.org). To compliment it, another handy tool would be a browser plug-in that could help create CSP rules based on how the site actually works. > A simpler syntax for simple case really would help, it's just that Ian > is coming a bit late for this. What specific changes do you recommend that would make it easier to use, but still function properly? There appears to be a disconnect between the audience CSP is actually targeting vs. the general audience some believe it is targeting. CSP is non-trivial; it takes a bit of work to configure it properly and requires on-going maintenance as the site evolves. It's not targeted to the uninformed author, it simply isn't possible to achieve that kind of coverage -- I suspect in the pool of all authors, the majority of them don't even know what XSS is, let alone ways to code against it and using CSP to augment defense. - Bil _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
