Sub Resource Integrity value for //maps.google.com/maps/api/js

mark vanzuela picture mark vanzuela · Sep 7, 2016 · Viewed 8.3k times · Source

Where do i find the sub resource integrity value for the script //maps.google.com/maps/api/js?

For example:

<script src="//maps.google.com/maps/api/js" integrity="sha256-????" crossorigin="anonymous"></script>

Answer

LinuxDisciple picture LinuxDisciple · Sep 1, 2017

You don't find the SRI digest for that script, and even if you did it wouldn't help you.

You don't:

SRI hashes are for content that doesn't change. Google changes the code that underlies their API all the time. You don't get to pick which version of the API to use; they choose for you, which is why there's no version number in that script path.

Using SRI for the Google Maps API script doesn't actually provide any additional security because that script's whole job is to download the newest version of a set of other scripts that actually provide the API functionality.

You can't use SRI to validate those other scripts, so you're already obligated to trust Google's security or forgo using their Maps API.

Even if you did, it wouldn't be helpful:

For scripts that don't download other JS files, try scrolling a bit lower down on the srihash.org site.

It says you can generate the SRI digest yourself using the Linux shell command openssl dgst -sha384 -binary FILENAME.js | openssl base64 -A

However that still won't help you with sources that don't serve the content with CORS headers because the browser requires CORS in order to do the SRI validation. The browser will decline to load the resource when it's been served without CORS headers even faster than if the SRI digests didn't match.

There's an explanation of the thought processes behind the decision to require CORS here: https://github.com/w3c/webappsec/issues/338#issuecomment-99766294

The upshot is that since SRI hashes are for all types of resources (not just JS and CSS files that have a legacy exception to the whole CORS thing) it could be used to get around same-origin policy enough to sniff otherwise inaccessible content.