Hi @ace0wp0syn
First of all, thank you for your suggestion.
Looking at the external scripts that are loaded from consent.cookiebot.com, there’s “cd.js” and “uc.js”.
Notice how “cd.js” is actually loaded from https://consent.cookiebot.com/<cookiebot_id>/cd.js. This means that the actual text content of this file will be different for every installation of the CookieBot plugin. The only way to verify this file’s content would be to create an option field where the site admin can configure the expected hash for this script.
On the other hand, “uc.js” is always getting loaded from the same URL. However, this URL lacks a version indicator. This most likely means that the “uc.js” text content might get updated at any point in the future. This means that if we implement the subresource integrity check, an update to the external “uc.js” script would break all CookieBot plugin installations.
As far as I know, there’s no sensible way to implement the subresource integrity feature for either of those scripts. Unless I’m missing something,
this feature only works for static and versioned resources.
If you have any objections, please feel free to bring them up. I would love to learn I’m wrong about this.
Kind regards,
Team AppSaloon
-
This reply was modified 4 years, 9 months ago by
monocode.
Does it means that the remote content of cd.js is different for each website or is this only the filename which is different? In both case you proposition to let the admin add by itself the expected hash is a good idea.
Regarding the uc.js script, without version control it is not so easy to handle. However, a solution could be to start a versioning of the file with a new update of the WordPress plugin. Each future update of uc.js will increment the uc.js version. This new version can be integrated in a plugin update.
Regards,