- From: Patrick Toomey <patrick.toomey@github.com>
- Date: Mon, 21 Dec 2015 17:34:34 +0000
- To: public-webappsec@w3.org
- Message-ID: <CAN4Q8dB9we__NeFY0cwaHKgY8EBuw6QAW6vAKV5iQkb6xrd6+A@mail.gmail.com>
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