Menu
I'm implementing global tracking on my site following the steps described by Google. But I want to also keep my Subresource Integrity (SRI) up to date. So I ran the following command to find the integrity hash for gtag.js.
> curl -s https://www.googletagmanager.com/gtag/js |\
openssl dgst -sha384 -binary |\
openssl base64 -A
Adding this as the integrity attribute to the script tag with the crossorigin="anonymous" attribute, causes the browser to fail loading the gtag script. Reason:
Subresource Integrity: The resource 'https://www.googletagmanager.com/gtag/js' has an integrity attribute, but the resource requires the request to be CORS enabled to check the integrity, and it is not. The resource has been blocked because the integrity cannot be enforced.
Apparent reason is the access-control-allow-origin header which google returns and only allows the same-host origin.
Does anyone know if there is a different host for this script? Is there another way to adopt gtag in your site?
405
Google Ads and Google Marketing Platform tags are fully supported by Tag Manager, and there is no need to deploy additional gtag. js-based code on your site if Tag Manager is already in use. If you're already using gtag. js, you can always upgrade to Tag Manager at a later date.
The Google tag uses the gtag. js JavaScript library to send data to Google Analytics. In addition to the Google tag, you can use Google Tag Manager to send data to Google Analytics. The Google tag was previously referred to as the global site tag.
A global site tag is made up of two snippets of JavaScript: a global snippet and an event snippet. Insert the global site tag between the <head> and </head> tags on every page of your site. The global snippet is placed on all pages, and the event snippet is additionally placed on pages with events you're tracking.
Place the <script> code snippet in the <head> of your web page's HTML output, preferably as close to the opening <head> tag as possible, but below any dataLayer declarations.
The only workaround for this may be to simply fetch the resource, store it on the same server, and then set your own Access-Control-Allow-Origin header.
This is a bit silly - because not only does it reduce the value of distributing the resource via CDN, it effectively makes the SRI pointless (because you're working with a static local copy, not a remote one the warrants reducing the risk of manipulation by verifying it with SRI).
This will also only work as long as the resource remains static. But since SRI depends on the resource being static (so that the hash will match), any change to the resource on the server would result in SRI enforcement causing the resource to fail anyway.
So it may be no more fragile than using SRI in the first place (unless you're generating the checksum of the resource on the fly ... at which point there's less of a point in using SRI in the first place).
UPDATE 2020-09-22: It looks like the issue may have been resolved on the Google side in April 2020.
59
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
