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

[CSP] "sri" source expression to enforce SRI

From: Patrick Toomey <patrick.toomey@github.com>
Date: Mon, 21 Dec 2015 17:34:34 +0000
Message-ID: <CAN4Q8dB9we__NeFY0cwaHKgY8EBuw6QAW6vAKV5iQkb6xrd6+A@mail.gmail.com>
To: public-webappsec@w3.org
We recently deployed subresource integrity across GitHub.com:
https://github.com/blog/2058-github-implements-subresource-integrity.
However, a few days after deployment we determined that one of our JS
scripts did not have an "integrity" attribute assigned to it. It was our
intent to add the integrity attribute to all subresources on GitHub.com. We
statically vendor in all CSS/JS and use Sprockets (SRI support was added in
https://github.com/sstephenson/sprockets/pull/645) to package these assets
for production deployments. There happened to be one JS file that had not
been vendored, and hence was not being packaged by Sprockets. This violated
two of our goals:

* Not allowing any dynamically sourced JS (we vendor everything to ensure
what is in version control is what is used in production)
* Enforcing SRI on all supported subresources on GitHub.com

Reflecting back on this situation, it would have been nice to have support
in CSP for a source expression such as
"sri"/"sri-only"/"sri-naming-things-is-hard" to ensure SRI is being used
everywhere. In the above scenario, the related JS would have failed to load
and we would have identified both of the issues listed above in testing.
Received on Tuesday, 22 December 2015 07:48:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:16 UTC