Re: [Content Security Policy] Proposal to move the debate forward

> 1) My site is entirely served over HTTPS, but my developers keep
> including mixed content by mistake.  I wish I could set a policy for
> my site that prevented me accidentally loading insecure content.

I think it's more complicated than that; it may be unacceptable to
include content simply from domains you don't control, or have no
assurances about: if you are a bank, you do not want any image or
stylesheet on your website to be replaced by "h4x0red by p1gZ" due to
a developer mistake.

I am not sure it's a problem that should be fixed on browser level;
but in terms of complexity, browser is definitely one of the most
attractive and reliable points (compared to, for example, server-side
auditing). And if there is a consensus that it's worth doing (?), then
doing it as a part of CSP probably makes more sense than devising a
separate mechanism.

>> 4. Clickjacking protection
>>   a. frame-ancestors: list of domains permitted to embed the resource
>>      in an iframe
> IMHO, clickjacking is a quagmire.  I'd love to see a solution, but I'm
> not really convinced that this is it.  I'd like to avoid being drawn
> into yet another discussion on this topic, if at all possible.

OK, but avoiding the topic of the validity of the fix: we already have
X-Frame-Options (and a proposal to extend them to allow ancestors to
be specified - David Ross is looking into this IIRC). Since the
mechanism sort of fits into this policy model, does it make sense to
keep it separate?

>From my perspective, the fewer policies / headers we need to tell web
devs about, and the fewer of them we need to keep examining, the
better. Of couse, there is the complexity argument, but I'd think that
the cummulative complexity of these two specs (XFO and
CSP-without-frame-ancestors) is higher than that of
CSP-with-frame-ancestors alone.

/mz

Received on Thursday, 27 January 2011 21:55:57 UTC