A script included with a script tag runs in the visitor's browser as part of your page. OWASP names three risks: loss of control over changes, arbitrary code execution in the browser, and leakage of user data to the vendor. How far a script can reach depends on how you include it.
The three risks
- Loss of control over changes. The vendor can change the file at any time. Your code review never sees it.
- Arbitrary code execution. The script can do what any page script can do: read the page, change it, and make requests.
- Data leakage. Even a well behaved script may send information about your visitors to the vendor, such as the page address and identifiers.
What a script on the page can usually reach
| Asset | Reachable by a normal script tag |
|---|---|
| Page content and form fields | Yes, the script can read and change them |
| Cookies without HttpOnly | Yes |
| Local storage for the page origin | Yes |
| Network requests | Yes, unless CSP limits destinations |
| Other scripts' variables | Often, through the shared page environment |
MDN's same-origin policy guide notes that read access is often leaked by embedding, including the actions of an embedded script. Storage is separated by origin, but a script that executes in your page context is acting for your origin.
HttpOnly cookies are protected from script reads, though a script can still make requests that carry them. See does HttpOnly stop XSS.
What an iframe changes
OWASP recommends loading vendor code in a cross-origin iframe with the sandbox attribute so it cannot reach your DOM or cookies, and exchanging messages with postMessage while checking the sender's origin. That moves the vendor to a smaller room. Which tokens to allow is covered in iframe sandbox tokens.
Controls, from cheap to costly
- Remove scripts you do not need.
- Pin version and add SRI where the file is static.
- Set CSP so scripts load only from known sources and connect only to known destinations.
- Limit tag manager abilities. OWASP suggests disabling custom HTML and JavaScript tags and restricting who can publish.
- Self-host where possible, which OWASP notes reduces data sent to third parties.
- Isolate in sandboxed iframes when the vendor allows.
- Monitor changes to vendor scripts on a schedule.
What to ask a vendor
Ask how they protect their own build and hosting, how they notify you of changes, whether they offer a version you can pin, and what data the script collects. OWASP suggests contracts should require evidence of secure coding and code integrity monitoring.
Where this connects to your dependency work
The scripts loaded by URL are one half of your front-end supply chain. The npm packages bundled in your build are the other. Safeguard covers that second half with SBOM and dependency scanning, and you can try a free scan at gold.safeguard.sh/scan.
Quick check
Can a third-party script read my password field?
If it runs in your page context, it can read form fields in that page. That is why payment and login pages deserve the fewest scripts.
Does HTTPS make a third-party script safe?
No. HTTPS protects the transfer. It says nothing about whether the file the vendor serves is trustworthy.
Sources
- OWASP, Third Party JavaScript Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html
- MDN, Same-origin policy: https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Same-origin_policy
Last reviewed: 19 October 2026.
