New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SRI tag helper security\fallback #79

KLuuKer opened this Issue Mar 8, 2016 · 3 comments


None yet
2 participants

KLuuKer commented Mar 8, 2016

As Damian on the community standup noted.
It's not secure to compute the hash on the server directly from the cdn (even if you cache the result).
Because the file could become compromised at some point in time.
Another note is this > CDNs fail, but your scripts don't have to - fallback from CDN to local jQuery

I would recommend uploading the required file to the server, use that to compute the hash (saves on download time).
And generate a fallback script for when the cdn fails or becomes corrupted like so:

<script src=""></script>
if (typeof jQuery == 'undefined') {
    document.write(unescape("%3Cscript src='/js/jquery-2.0.0.min.js' type='text/javascript'%3E%3C/script%3E"));

and of course you could add the SRI tag to both script elements


This comment has been minimized.


RehanSaeed commented Mar 9, 2016

My initial thinking was that you could check the files at deployment time when the tag helper first runs. Then the tag helper would have calculated the hash and cached it without any expiration time, so you are good from then on. That's still more secure than 'every site on the internet' as Jon Galloway put it in the ASP.NET standup.

I suppose that checking the files on every deployment is not great for the developer. So for the next iteration I will add an alternative source, basically a local file from which the SRI is calculated. Someting like this:

<script src="https://somecdn/jquery.js" 

In this scenario, the developer would have to check the file for validity every time they upgrade it. I'm not 100% sure if dropping the call to the CDN resource is the way to go. If we kept the call, we could compare the SRI and log an error, giving the developer some quick feedback to something they might otherwise miss if they are using script fallbacks. Perhaps this should be an option?

There is already a fallback script tag helper built in which pretty much generates the code you wrote. However, I prefer not to use them because they are not compatible with Content Security Policy (CSP) because they require the use of inline scripts.


This comment has been minimized.


RehanSaeed commented Mar 12, 2016


This comment has been minimized.

KLuuKer commented Mar 14, 2016

Looks great, I totally forgot about the fact that core already has it included (I'm currently still stuck on until I get my app rebuilt for core).

As far as I'm concerned you can close this issue.

@RehanSaeed RehanSaeed closed this Mar 14, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment