Third-Party Script Risk Analyzer

List every external script a page loads with its origin, loading strategy, SRI status and referrer exposure, so supply-chain risk is visible rather than assumed.

Passive public check

a2z.tools reads publicly visible information from the address you enter. It is a read-only request - nothing is submitted, changed or probed.

Page address Reads the page HTML and lists the scripts it references. The page is not executed.

Every third-party script is a party with full access to your page

A script you include from another origin runs with exactly the privileges your own code has. It can read the DOM, read any cookie that is not HttpOnly, observe what visitors type into forms, and make requests as the visitor. That is not a criticism of any particular vendor - it is simply what including a script means, and it is worth being deliberate about how many parties have that access.

This tool lists the scripts a page references, tells you which are third party, and reports what is and is not protecting each one.

It reads markup, it does not run the page

The analyser fetches the HTML and parses it. Anything injected later by JavaScript - which is most tag-manager content, much advertising and some analytics - is not in the markup and does not appear here. That is an honest limit rather than an oversight: executing a visitor-supplied page on our servers to see what it loads would be a far larger problem than the one it solves. A tag manager in particular can load anything at any time, which is exactly why the tool flags the loader itself.

Where Subresource Integrity helps, and where it cannot

SRI pins the exact bytes of a file. The browser hashes what it receives and refuses to run anything that does not match, which means a compromised CDN or a hijacked publishing account cannot silently change what executes on your page.

It only works on files that do not change. A versioned library on a CDN is the ideal case. A tag manager, an analytics bootstrap or any /latest/ URL is meant to change, and pinning it would break your site on the vendor's next release.

So this tool splits them. Files that look pinnable get an SRI finding with the fix. Files that look intentionally mutable are reported separately, as a heuristic, with the honest answer: SRI is not available to you here, and the control is a Content Security Policy restricting what those loaders can reach. Recommending SRI for a tag manager would be advice you could not follow.

Generate hashes with SRI Hash Generator and build the policy with CSP Generator.

The other things this reports

Scripts over plain HTTP. These can be replaced in transit, and replacing a script means controlling the page. Browsers already block this on an HTTPS page, so it is usually broken as well as unsafe.
Render-blocking third-party scripts. An availability point rather than a security one, and the most common way a third party takes a site down: a synchronous script means your page's availability depends on theirs.
Detected library versions, where the URL states one. Feed those into Vulnerable JavaScript Library Checker.

This tool does not claim to detect malware

It reports what is loaded, from where, and with what protections. It does not fetch and analyse the script contents, and it will never tell you a script is malicious - that judgement needs evidence this method cannot produce, and a tool that guessed would be doing more harm than good. What it gives you is the inventory, which is the thing most teams do not have.

Frequently asked questions

Why is a script I can see in DevTools not listed?

Because it is injected at runtime rather than written in the HTML. This tool parses the markup and does not execute the page. A tag manager, for instance, appears here as one script - everything it subsequently loads does not.

Should I add SRI to everything?

No. Add it to files that are meant to be stable, which is versioned libraries on a CDN. Adding it to a tag manager or a "latest" URL breaks your site the next time the vendor ships, which is why this tool separates the two rather than recommending it uniformly.

Is a third-party script automatically a problem?

No. Nearly every site has them. The point is knowing how many parties have full access to your pages, whether each is pinned, and whether the list still matches what you think you are running.

Does this tell me if a script is malicious?

No, and it deliberately will not guess. It reports origin, loading strategy and integrity. Claiming malware without evidence would be worse than saying nothing.

References

Related tools

What this tool can and cannot tell you. It reports the configuration a site exposes to an ordinary visitor. It does not log in, submit anything, or test for vulnerabilities, so a passing result means the public configuration looked correct at the moment of the check - not that the site is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.