Third-Party Script & SRI Audit
Every third-party script your page loads runs with your page’s full privileges — it can read the DOM, watch form input and act in your visitors’ sessions. This audit fetches a page’s static HTML, lists every external script it references, marks which ones are third-party, which carry a Subresource Integrity (SRI) hash, and which are pinned to an exact version — and for third-party scripts missing integrity, it computes the sha384 hash so you can paste it straight into the tag.
Last updated:
Worried a vendor script on your site might change or go down? Monitor this free with myeventwatch — expiry and downtime alerts, no card required.
What this audit checks — and what it cannot see
The checker fetches the page once and parses the HTML it is served — the static HTML only. Every <script src> in that markup is listed with its host, classified as first-party when the host matches your page’s registrable domain and third-party when it does not, and checked for the two attributes that decide whether the browser can protect you: integrity, the SRI hash the browser verifies before running the file, and crossorigin, which a cross-origin SRI check needs in order to work. The version in the URL is assessed too: a script addressed as [email protected] or /v2.4/ is pinned, while a latest or unversioned address is a moving target whose contents can change at any moment without anyone touching your site.
Be clear about the boundary, because it matters: v1 parses the page’s static HTML only — scripts injected at runtime by JavaScript are not covered. Tag managers, consent tools and chat widgets routinely create script elements from code after the page loads, and a static parse never sees them. Treat this audit as the inventory of what your templates and CMS directly reference — usually the largest and most fixable part of the problem — and audit tag-manager containers separately, in the manager’s own preview and change history. Inline scripts (blocks with no src) are counted as a fact on the result, because they cannot carry SRI at all; the companion guide explains what to do about them.
The hash column: computed, never guessed
For third-party scripts that lack an integrity attribute, the checker fetches the script itself — through the same SSRF-guarded fetch path as every other checker on this site, capped at the first 15 such scripts and 512 KB each — and computes its SHA-384 hash. When that fetch succeeds, the SRI cell shows the full snippet, integrity="sha384-…", ready to paste into your tag next to crossorigin="anonymous". A hash is only shown when the script was actually fetched. If the fetch failed, the file was too large, or the script fell beyond the 15-script cap, the cell shows that note instead — never a placeholder or a guessed value — and the fix is to generate the hash in your own build pipeline, where the exact file is at hand.
Related checks: the security headers check grades the response headers — including the Content-Security-Policy that is SRI’s natural partner — the SSL grader covers the transport those scripts arrive over, and the companion article third-party scripts are a supply-chain risk walks through a real incident, what SRI does and does not stop, and a repeatable audit routine.
How the verdicts should be read: a third-party script with integrity and a pinned version is the healthy case — the browser will refuse a swapped or edited file. A third-party script without integrity is not automatically malicious; it is unprotected, meaning its contents are whatever its host serves today, and your only warning of a change would be the damage. Unpinned addresses deserve the same suspicion as missing hashes, because an SRI hash over a latest URL breaks the first time the vendor ships an update — which is why the two findings are reported side by side, and why the durable fix is always the pair: pin the exact version, then hash exactly that file.
The facts this page shows
| Third-party | A script whose host’s registrable domain differs from the page’s — code served by someone else, running with your page’s privileges. |
| Integrity (SRI) | Whether the tag carries an integrity attribute: a cryptographic hash the browser checks before executing the file, refusing it on any mismatch. |
| Crossorigin | Whether the tag carries the crossorigin attribute a cross-origin SRI check requires; without it, browsers cannot apply SRI to the load. |
| Pinned | Whether the URL names an exact version ([email protected], /v2.4/) rather than a floating latest or unversioned address whose contents can change silently. |
| Computed SRI | For third-party scripts missing integrity, the sha384 hash the checker computed by actually fetching the file — shown only on a successful fetch, for the first 15 such scripts. |
Frequently asked questions
Does this audit see every script my page runs?
No — and the page says so plainly: v1 parses the page’s static HTML only, so scripts injected at runtime by JavaScript are not covered. Tag managers, A/B testing tools, consent banners and chat widgets commonly inject scripts after load; audit those in the tag manager or with a browser’s network panel. What this audit covers completely is every script your served HTML directly references, which is where libraries, CDN widgets and monitoring embeds live.
Where does the hash in the SRI column come from?
The checker fetches the script file itself and computes its SHA-384 hash, for third-party scripts missing an integrity attribute — the first 15 of them, up to 512 KB each. A hash is only shown when the script was actually fetched: if the fetch failed, the file was too large, or the cap was reached, the cell shows that note instead of a hash. Paste the snippet into your script tag together with crossorigin="anonymous", and re-run the audit after any version change — a new version means a new hash.
My tag manager script cannot have a fixed hash. What then?
Correct — a tag-manager container is designed to change, so SRI cannot pin it, and the same is true of any script whose whole purpose is to load changing code. For those, the controls are different: restrict who can publish to the container, review its change history like code changes, load it only on the pages that need it, and use a Content-Security-Policy to limit what injected scripts can do and where they can send data. SRI protects the fixed libraries; governance protects the dynamic ones.
Is a missing integrity attribute an emergency?
It is a standing exposure, not an incident. The script is almost certainly the file the vendor intends to serve today; the problem is that nothing would stop or flag a different file tomorrow — after a vendor compromise, a hijacked account or a lapsed domain. Fix order: scripts on pages with logins, payments or personal data first, then pinned-and-hashed libraries everywhere else, then the long tail. Each fix is a one-line tag change once the version is pinned.
Why does the pin column call a script “latest” or “unversioned”?
The pin verdict is a heuristic read of the URL: a version-looking segment such as @1.2.3 or /v2.4/ counts as pinned, an explicit latest segment counts as floating, and a URL with no version anywhere counts as unversioned. It is labelled a heuristic because only the vendor knows their release scheme — but the security point does not depend on the label: if the bytes at that URL can change without the URL changing, an SRI hash cannot survive, so pin first, then hash.