Securing and Trusting Third-Party Javascripts in Your Web App

The talk starts by defining third-party JavaScript as code served from external servers that a site owner does not write or control, such as analytics, advertising and social sharing widgets. It then covers the three common ways these scripts reach a page: a direct script tag pointing at a vendor URL, vendor code pasted inline, and loading everything through a tag manager. Tag managers are popular with marketing teams because they let non-developers add or change scripts without redeploying the app.

The talk then turns to risk. A script running in the page gets full access to the DOM, can read sensitive input such as payment details, and can be changed by its owner at any time. The card-skimming attacks against shared checkout scripts show how compromising one vendor can expose many sites at once. Mitigations discussed include a Content Security Policy with script-source directives and nonces, which limits what loads but does not inspect what a script does; an iframe, which blocks DOM access but breaks analytics and tag managers that need the page; and Subresource Integrity, which pins a script to a hash. SRI fits poorly with tag managers, since their containers change without a code deploy and the hash goes stale.

The closing advice is practical. Keep scripts off sensitive pages such as checkout or password change where possible, teach teams that use tag managers about the risks, and bring in vendor security and legal reviews before trusting a provider. When a dynamic script must touch the DOM, the remaining risk is assessed, CSP is used as a baseline, and what is left is formally accepted.