Fetch each vendor script on a schedule, store its hash and a copy, and alert when the hash changes. Back this with CSP and integrity violation reports from real browsers, and a human review of each diff. OWASP advises watching vendor JavaScript for unexpected changes on a regular schedule.
Why you need this even with SRI
SRI blocks a changed file, but only for scripts you can pin. For scripts that must stay dynamic, nothing tells you when the content moves. Monitoring is how you notice.
Three signals
| Signal | Catches | Limit |
|---|---|---|
| Scheduled fetch and hash | Any byte change at the URL | The server may return different content to your monitor than to users |
| Browser reports (CSP, integrity) | New domains and blocked loads seen by real users | Only for things your policy covers |
| Behavior checks in a test browser | New requests, new cookies, new storage use | Needs a script that visits key pages |
Build the fetch and hash monitor
- Take your script inventory and list the dynamic ones.
- Write a job that fetches each URL and saves the body and its SHA-256 hash with a timestamp.
- Compare to the last stored hash. On a change, save a diff and notify the script owner.
- Fetch from more than one network location and with a browser like user agent string, since a malicious server may serve different content to bots.
- Keep history for at least as long as your incident review window.
For scripts that load other scripts, record the whole chain, not only the first file.
Add real browser signals
Set a report-only CSP that reports unexpected script and connection destinations, see CSP report-only rollout steps. MDN says reports are sent as JSON by POST to the endpoint you name with report-to. If you enforce Integrity-Policy, violation reports show a blocked URL and destination, see the Integrity-Policy header.
Add a synthetic browser run on key pages that records every request after load. A new domain or a new beacon after a vendor release is a useful alarm.
Triage a change
- Is there a vendor release note or a matching version bump?
- Does the diff add new network destinations, new cookie access or new form reading code?
- Does it match a pattern you know, such as an analytics update?
- If unclear, ask the vendor, and consider pausing the script on sensitive pages.
Minified diffs are hard to read. Format both versions before comparing, and focus on URLs and function calls that touch forms, cookies or storage.
Who owns it
Give every dynamic script an owner on the team that uses it, not only the security team. The owner decides whether to keep, pin or remove it.
Safeguard covers the dependency side, with SBOM and dependency scanning and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how ongoing checks raise an alert when something changes.
Quick check
How often should I fetch the scripts?
Daily is a reasonable start for sensitive pages. Match the frequency to how fast you could react to a change.
Can a script serve different content to my monitor?
Yes, that is possible. Fetch from several locations and pair the hash check with browser reports from real visits.
Sources
- OWASP, Third Party JavaScript Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html
- MDN, Content Security Policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
- MDN, Integrity-Policy header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Integrity-Policy
Last reviewed: 19 October 2026.
