Is there any implementation or specification for including a hash or signature in an attribute of a <script> tag, so that the browser can verify that the correct file was retrieved before executing it? Something like:

<script
  src=".js"
  signature="sha-256/e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
></script>

The motivation is this: generally, each additional CDN or host you use for your site increases your vulnerability, by adding a new target that can be hacked to compromise your site. Allowing your primary front-end servers to assert hashes or signatures of those files could entirely eliminate that risk, allowing you to be more flexible when designing your architecture. You could even request missing files from an untrusted peer-to-peer network.

I thought I remembered a specification about this, but haven't been able to find it.

Is there any implementation or specification for including a hash or signature in an attribute of a <script> tag, so that the browser can verify that the correct file was retrieved before executing it? Something like:

<script
  src="http://cdn.example.com/jquery-2001.js"
  signature="sha-256/e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
></script>

The motivation is this: generally, each additional CDN or host you use for your site increases your vulnerability, by adding a new target that can be hacked to compromise your site. Allowing your primary front-end servers to assert hashes or signatures of those files could entirely eliminate that risk, allowing you to be more flexible when designing your architecture. You could even request missing files from an untrusted peer-to-peer network.

I thought I remembered a specification about this, but haven't been able to find it.

• javascript
• html
• cryptography
• subresource-integrity

• There is no signature attribute. Why do you need this? – Ram Commented Mar 26, 2015 at 3:34
• I didn't expect this to be in the accepted standards yet, but thought there was a proposal that had been implemented on some platform. signature was an example of what the name could be -- I'd expect the real name and syntax to be more well-thought-out than my example. – user4714902 Commented Mar 26, 2015 at 3:37
• Something like this is necessary to be able to use shared CDNs (like the ones provided by jQuery), or CDNs in general, without increasing your security risk. Generally, each additional CDN service you add means one more service that could be hacked to compromise your site. If your primary site can assert hashes/signatures of the files it's referencing, that risk is eliminated. I'm sure we will have a standard eventually. – user4714902 Commented Mar 26, 2015 at 3:39
• 2 Well, this can be a good security layer and makes sense! You can load the file programmatically and leave the validation to your application. I live in a country that it's stupid government filters domains randomly for no particular reason and do not use CDNs. – Ram Commented Mar 26, 2015 at 3:41
• Some more info: w3.org/Bugs/Public/show_bug.cgi?id=20789 – Jeremy Banks - Vive le Canada Commented Apr 2, 2015 at 7:50

2 Answers 2

This feature was proposed by the W3C as Subresource Integrity. As of December 2015, this recommendation has been implemented by Chrome 44 and Firefox 43.

EXAMPLE 1

<link rel="stylesheet" href="https://site53.example.net/style.css"
      integrity="sha256-vjnUh7+rXHH2lg/5vDY8032ftNVCIEC21vL6szrVw9M="
      crossorigin="anonymous">

There is a superficially similar feature in Content Security Policy Level 2, but it only restricts the contents of inline <script> and <style> elements, not external ones.

It does not look like it is supported according to Mozilla Developer Network docs:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script

However, you could always fetch a resource via XHR (assuming CORS is configured), hash it, and if it is cool, eval(). However, while an interesting technical exercise it does not seem practical.