Managing third-party scripts safely: inventory, SRI, CSP and form destinations

Start with an inventory. Include scripts written directly into your HTML, tags configured in your tag manager, and anything a library or plugin loads on its own.

For each one, record the origin it loads from, whose service it is, why it was added, which pages it runs on, and who switches it off, and how, if something goes wrong. Also list iframes, images and other resources that connect to outside servers; the list then doubles as the input for your CSP.

Anything in the list with no known purpose or no owner is a candidate for removal. Old campaign tags and analytics services you have already replaced are often still there.

On pages where input is valuable, such as login, payment, password or email changes, and admin screens, keep only what is needed. A tag placed in a site-wide template also lands on these pages, so decide per page type what loads. For widgets that do not need to touch the page, OWASP describes isolating them in an iframe on a separate domain with the sandbox attribute.

OWASP warns that a data layer (the object holding values passed to tags) is not a sandbox, and that tag-manager containers can run custom JavaScript and HTML tags. It recommends restricting publishing access and reviewing changes as you would application code.

In practice, start with four things: limit publishing to a few people, turn on two-factor authentication for tag-manager accounts, disable custom HTML tags if you do not need them, and have a second person review before publishing.

SRI (Subresource Integrity) lets you put a hash of the file in an integrity attribute on <script> and similar elements; if the file the browser receives does not match, it refuses to load it. According to MDN, the allowed hashes are sha256, sha384 and sha512, a cross-origin file needs the provider to allow CORS, and you also add the crossorigin attribute.

SRI only works for files whose content does not change, such as a versioned library. On an analytics tag that the provider updates at will, every update breaks loading. In that case, serve a reviewed copy from your own site (what OWASP calls in-house mirroring) or do not load it on sensitive pages. To check libraries for known vulnerabilities, paste your lockfile into the dependency vulnerability scanner.

In your Content-Security-Policy, allow the origins from your step 1 list. script-src restricts where scripts load from; connect-src restricts where fetch, XMLHttpRequest, WebSocket, EventSource, sendBeacon and similar APIs can connect (MDN).

form-action, which restricts where forms submit, does not fall back to default-src. MDN states that not setting it allows anything. If your forms only post to your own site, set form-action 'self' explicitly.

Enforcing a new policy at once can break legitimate features, so collect violation reports first with Content-Security-Policy-Report-Only. MDN notes that reports are only sent if you specify report-to, and that this header is not supported in a <meta> element (the deprecated report-uri also still works). You can try policies in the CSP Builder; for headers in general, see choosing security headers.

Third-party scripts change without any action on your part. At a fixed interval, for example monthly, compare your list with what actually runs, and investigate any unknown destination that appears in CSP violation reports. Subscribe to the providers' security notices.

Document which tag is switched off, by whom, and from which screen when something goes wrong. If you run card payment pages, also note that PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 on payment page security have been effective since 31 March 2025 (PCI SSC). For merchants that validate with SAQ A, whose account data functions are fully outsourced to compliant third parties, those two requirements are replaced by an eligibility criterion to confirm that their site is not susceptible to attacks from scripts that could affect their e-commerce systems; the requirements in the standard itself do not change.