If we do want to support this use case, it seems like having a parallel
mechanism to script-src would be intuitive. If you're not using style-src,
you can use inline styles, and if you do use style-src, you specifically
have to opt in to inline styles as one of the sources that you allow.
So perhaps "inline" or "unsafe-inline" could be a special source (just like
"none" and "self") that is allowed for both script-src and style-src,
instead of having the magic "disable-xss-protection" directive.
Collin
On Wed, Apr 6, 2011 at 12:56 PM, Brandon Sterne <bsterne@mozilla.com> wrote:
> On 04/06/2011 12:33 PM, Collin Jackson wrote:
> >
> >
> > On Wed, Apr 6, 2011 at 11:40 AM, Brandon Sterne <bsterne@mozilla.com
> > <mailto:bsterne@mozilla.com>> wrote:
> >
> > Personally, I think consistency is desirable, but not if it makes the
> > work of CSP server implementors necessarily hard ("now go remove all
> > instances of inline style") for limited benefit.
> >
> >
> > Presumably most authors are not going to use style-src since it doesn't
> > solve any XSS problems. Blocking inline styles for people who do use
> > style-src seems both consistent and desirable.
>
> What about a secure site that only wants to load their stylesheet over
> TLS? It is asking them to do quite a lot of work if we require they
> remove all inline CSS.
>
> -Brandon
>
Received on Wednesday, 6 April 2011 20:06:41 UTC