Re: CSP and default policies

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 UTC