W3C home > Mailing lists > Public > public-web-security@w3.org > April 2011

Re: CSP and default policies

From: Gervase Markham <gerv@mozilla.org>
Date: Sat, 02 Apr 2011 11:39:42 +0100
Message-ID: <4D96FCEE.3050009@mozilla.org>
To: Brandon Sterne <bsterne@mozilla.com>
CC: public-web-security@w3.org
On 01/04/11 22:24, Brandon Sterne wrote:
> If you do not agree that the topic of version compatibility is
> unavoidable, consider the two following cases which should ideally both
> be supported:
> A. a web site presently enumerates the full set of capabilities that
>     it needs in order to function and wishes to express a policy that
>     restricts all capabilites beyond this set
> B. a web site presently knows that it wants to express a policy
>     prohibiting a risky set of capabilities, but does not want to
>     introduce breakage at any point in the future if changes are made
>     to CSP

I acknowledge your point, and suggest that the solution is that we do 
not support use case B. (IOW, I support model 1, that you call the 
"white-list".)

CSP can not be both default-block and default-allow. Trying to make it 
both is, IMO, doomed to complexity failure.

Many have ranted over many years about how the web security model is in 
many places default-allow, and we keep having to try and patch more 
restrictions in while keeping web compat. CSP is a great opportunity to 
do default-deny - opt in to CSP, and a bunch of exploit types just stop 
working. If we go for default-allow, then we are back in a "oh, add 
another directive to close _that_ hole, and evangelise everyone to adopt 
it" mess.

If frame-ancestors is different enough that people want to specify it on 
its own without changing JS behaviour, then it should be in its own 
header. Perhaps (to avoid further proliferation) a new one with the same 
sort of extensible syntax, which can be used for a number of future 
security ideas, each of which is independent of each other.

Gerv
Received on Saturday, 2 April 2011 21:57:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 2 April 2011 21:57:00 GMT