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

Re: style-src and inline style

From: Collin Jackson <collin.jackson@sv.cmu.edu>
Date: Thu, 14 Apr 2011 21:48:09 +0000
Message-ID: <BANLkTi=uEXZBXfguovmTHOMcHJm1FG5z0A@mail.gmail.com>
To: Brandon Sterne <bsterne@mozilla.com>
Cc: Adam Barth <w3c@adambarth.com>, Bil Corry <bil@corry.biz>, gaz Heyes <gazheyes@gmail.com>, Daniel Veditz <dveditz@mozilla.com>, public-web-security@w3.org
On Thu, Apr 14, 2011 at 8:51 PM, Brandon Sterne <bsterne@mozilla.com> wrote:

> On 4/11/11 11:19 AM, Brandon Sterne wrote:
> > On 4/7/11 9:17 AM, Collin Jackson wrote:
> >> I'd like to suggest option 3, which is to block inline styles by default
> >> only if a style-src directive is present (authors can use style-src
> >> 'inline' if they want to use style-src with inline styles).
> >>
> >> Attaching default blocking behaviors to specific directives rather than
> >> to the entirety of CSP makes the spec more extensible and allows us to
> >> support a variety of use cases while still keeping policies simple.
> >
> > I think this is the best solution offered so far.  If there are no
> > objections, I'll make this change to the spec draft as well.
>
> I'm in the process of making this change, and I'm wondering how best to
> extend this to be consistent with script-src.
>
> The proposal is to disable inline style when style-src is present and
> only allow it when the 'inline' keyword is added to style-src.
>
> For script-src, however, adding the 'inline' keyword to script-src is
> less desirable than the disable-xss-protection options token we had
> previously (from the standpoint of conveying sufficient caution when
> enabling inline script).  One option would be to change 'inline' to
> 'inline-style' that only has an effect when declared inside style-src,
> and have a different keyword for inline script, potentially keeping
> 'disable-xss-protection'.  Yes, that would be less consistent
> syntactically, but it would preserve the "Foot Gun Here" element.
>

A few alternatives (not sure if they're better, but just throwing them out
there):

* Use the keyword "unsafe-inline" instead of "inline." Is that scary
sounding enough?
* Ignore the keyword "inline" unless the disable-xss-protection directive is
present. Authors would need to use both disable-xss-protection and
script-src inline if they want to allow inline script with a script-src
directive present.
Received on Thursday, 14 April 2011 21:59:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 14 April 2011 21:59:33 GMT