We would not expect this insecurity here, wouldn't we?

Checked some code that we find as third party code on many a website,
and we better make sure that it is “same origin”
with the appropriate SRI hashes.

Re: http://www.domxssscanner.com/scan?url=http%3A%2F%2Fajax.googleapis.com

So I visited the site where these developer codes reside and scanned to get a SRI Report.

It gave me a meagre F-Status in return:
https://sritest.io/#report/e57bd082-cf2a-473d-ab50-996b8f4daee0

And this retirable is not cheering us up either:
-https://developers.google.com/speed/libraries/
Detected libraries:
jquery - 2.2.0 : (active1) -https://ajax.googleapis.com/ajax/libs/jquery/2.2.0/jquery.min.js
Info: Severity: medium
https://github.com/jquery/jquery/issues/2432
http://blog.jquery.com/2016/01/08/jquery-2-2-and-1-12-released/
jquery-ui-dialog - 1.11.4 : (active1) -https://developers.google.com/speed/libraries/
jquery-ui-autocomplete - 1.11.4 : (active1) -https://developers.google.com/speed/libraries/
jquery-ui-tooltip - 1.11.4 : (active1) -https://developers.google.com/speed/libraries/
(active) - the library was also found to be active by running code
1 vulnerable library detected

How could that be for code that so many a website developer depends on?

And then we also have to live with this - in the Crypto Report on the Certificate:
-developers.google.com
Warnings
RSA remove cross certificates
The certificate chain contains a cross root (primary intermediate) certificate that should be removed. Use Symantec CryptoReport to remove cross root certificates.
ECC remove cross certificates
The certificate chain contains a cross root (primary intermediate) certificate that should be removed. Use Symantec CryptoReport to remove cross root certificates.

Consider also: http://www.domxssscanner.com/scan?url=https%3A%2F%2Fdevelopers.google.com

Good we did not find any direct errors in a DOM XSS vuln. script like /script_foot.js there.
Keep these codes in good order, folks, as there was a bug filed in this very code January last:

polonus (volunteer website security analyst and website error-hunter)

Conclusion,

I understand that code comes as “fit to be used” and not completely bug-tested or pen-tetsted.
Understandably so, there is an enormous amount of work left to be done to get a bit more secure infrastructure.

I also understand that it is a good advice to have your embedded code hosted by Google (jQuery library code for instance),
and not do it yourself, based on Google developer’s assumed expertise.

But again this third party embedded code should be secure content (same origin rule)
as well and often we find SRI hashes missing here were not generated.

So Google development should take it’s responsibility here as well.
CSP should beintroduced where it can be introduced.
I like my browser to be told what is secure content and what is not.

polonus (volunteer website security analyst and website error-hunter).

Why you should protect your embedded content on cdn’s and why you should generate sri-hashes can be clear from this info:

https://www.troyhunt.com/protecting-your-embedded-content-with-subresource-integrity-sri/

Protect the integrity of your embedded script.

polonus