W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2015

[CSP] data: vs * in the real world

From: Daniel Veditz <dveditz@mozilla.com>
Date: Fri, 24 Apr 2015 01:33:37 -0700
Message-ID: <CADYDTCCPtCusRgRboTbrskzgJz1YFo+TXm-TSnxzxzoYwj+BYg@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
According to the CSP spec * should not match data: (and similar schemes).
Firefox's original implementation of the X-Content-Security-Policy header
behaved that way, but the original translation to the spec-compliant
Content-Security-Policy did not at first. When we recently started
enforcing that part of the spec we immediately found several sites that
broke because they were using img-src * or default-src * and data: sourced
images. These are not backwater sites we can just ignore: WhatsApp, CNN,
Fastmail (and Html5test, but I'm less pessimistic about convincing them).


We're not sure what the best way forward is at this point but none of the
options are all that great, especially considering the WG thinks we're done
changing CSP2 and are on to CSP.next.

a) try tech evangelism to get the sites to fix their CSP, even though
"works in Chrome"
b) change the spec to match what everyone is doing anyway -- but then we
have effectively allowed unsafe-inline
c) change the spec so that _sometimes_ * matches data: (safe things like
images, which is most of the problem anyway) and other times doesn't match
in unsafe directives (like script-src and frame-src). html5test is using it
for javascript but I'm less concerned about being unable to successfully
convince them to change.
d) have '*' always match data:, but _also_ require an explicit
'unsafe-inline' to use it for script-src, style-src, frame-src, child-src,
and object-src (where it's unlikely to be currently used anyway).

My Chrome bug searching skills aren't great, but I didn't see any bugs
about chrome changing this behavior. Found one for blob: and 'self', but
that's a different (similar) issue.

-Dan Veditz
Received on Friday, 24 April 2015 08:34:05 UTC

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