W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2016

Fwd: XSS-Protection notes

From: Artur Janc <aaj@google.com>
Date: Mon, 10 Oct 2016 11:01:59 +0200
Message-ID: <CAPYVjqqZ+RvjVT0e2Wo=uSN9j0LOurXV8xY_a8CNCuSmWYivVw@mail.gmail.com>
To: WebAppSec WG <public-webappsec@w3.org>
Hey webappsec,

I'm forwarding a short thread we had with Mike about the XSS-Protection
proposal -- I tried to trim it down a bit, but apologies if it's still hard
to follow. FWIW some of this is similar to the questions Dave raised on the
parallel thread (


---------- Forwarded message ----------
From: Artur Janc <aaj@google.com>
Date: Sat, Oct 8, 2016 at 11:46 PM
Subject: Re: XSS-Protection notes
To: Mike West <mkwst@google.com>
Cc: Thomas Sepez <tsepez@google.com>, Krzysztof Kotowicz <koto@google.com>,
David Ross <drx@google.com>

> > 1. I'm not entirely sold on the idea of having a different syntax for
> CSP without giving developers additional useful functionality. Because of
> missing browser support developers will have to either use both mechanisms
> or have middleware which would reformulate XSS-Protection as CSP, at which
> point they won't really need the simpler syntax.
> I agree with you, but I discount the importance of the objection, given
> that 90% of pages don't have this problem, because they have no protection
> in status quo. If we can get another 10% of pages using a simpler syntax,
> that's a huge win for the web, even if it only works in Chrome.

But if you go through the effort to understand the benefits of the
mechanism, apply nonces in your application and make sure everything works,
then if a simple string transformation is all you need to have it apply in
all browsers, you'd probably just use regular CSP...

> 2. Somewhat related, we'd need a few more things from CSP which aren't
> currently in the proposal, e.g. 'unsafe-eval' and a Report-Only mode.

I thought you were getting away without eval? *sigh*

We use 'unsafe-eval' by default but we don't care because there are
relatively few XSS-es in APIs allowed by eval(), etc and its wrappers. But
yeah, it's pretty rare to be able to avoid it in our applications.

> If you need report-only, use CSP. :) That sounds glib, but really: 0.3% of
> pages use a report-only policy. All sanity aside, it's a power-user
> feature. (That said, it's trivial to add, so whatever.)

Hm, our data says something very different: out of the 1.6M domains with
CSP, 70% use it as Report-Only. This is skewed by a couple apps deployed on
hundreds of thousands of domains; but looking at unique policies it's still
~10%. The thing is that pretty much every app needs to do some testing
before enabling enforcing mode, even if it's just for a short time, or in a
staging environment. Having to "do it live" would be a fairly big

> > It's possible to add new fields to the JSON object but it will just end
> up duplicating a lot of keywords from script-src. At some point it might
> not be much more compelling than a CSP of "script-src 'nonce-foo'
> 'strict-dynamic' 'unsafe-inline' https:; report-uri /foo".
> Aesthetics and ergonomics are compelling reasons to hide the current
> syntax from developers.

But now we're introducing a new syntax which isn't really obvious, and
bundles together parts of CSP and a weird under-specified XSS filter
behavior. I could see the appeal of something like "Require-Script-Nonce:
<nonce>" but I guess XSS-Protection does not seem all that much simpler...

I guess I'm arguing for both more and less features at the same time; I'm
not entirely sure what makes more sense ;-)

> 3. Blessing X-XSS-Protection by putting it in the new shiny thing sounds
> a little anachronistic because it looks like XSS filters are on their last
> legs (...)

> +tsepez, who will have opinions.
> 1. I think there's a big difference between "Google is going to turn off
> the auditor." and "The auditor does more harm than good for most pages."
> That said, I _would_ like us to change our default from filter to block
> (and maybe remove the filter option entirely? :) ). Maybe this is a good
> time to do that.
> 2. We need to write down the high-level behavior of `X-XSS-Protection`
> somewhere. Might as well be here.

It seems to me that if we're trying to be forward-looking and build a
prescriptive mechanism to help developers mitigate XSS, it's fine to omit
parts of the platform that don't seem crucial. For example, XSS-Protection
wouldn't include X-Content-Type-Options: nosniff or CSP whitelists even
though they are arguably anti-XSS mechanisms.

If XSS filters don't offer meaningful protection (which tends to be a
fairly common view among security people) then I'm not sure the advantage
of including them is worth the developer-facing complexity.

> 4. Precedence of headers. Will X-XSS-Protection be ignored by supporting
> UAs? If you have a semantically equivalent CSP for backwards-compatibility,
> will you get duplicate reports?

Currently, both would be applied via the combining logic in
> https://mikewest.github.io/artur-yes/#initialize-document-xss. Ignoring
> `X-XSS-Protection` is simpler, and probably equally valid (but we still
> need the combining logic for multiple `XSS-Protection` headers, so it
> doesn't buy us much in terms of complexity).
Received on Monday, 10 October 2016 09:02:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:58 UTC