"Who allowed you to do that?" Detecting and Controlling Rogue Third-Party Scripts

Brad Burkle opens with the shift to web applications built on third-party JavaScript, where a typical page may load dozens of outside scripts that run with the same access as the site's own code. Browser-side attacks such as payment card skimming happen outside the server perimeter, so web application firewalls and periodic code reviews often miss them. He cites a large retailer that watched a 30-hour Black Friday window and recorded roughly 144,000 attempted data exfiltrations, about 9,000 of them involving sensitive data.

The middle of the talk covers why this persists: fast release cycles, scripts that change without review, and security teams that lack visibility. Content Security Policy and Subresource Integrity can help, but they need constant upkeep. The proposed approach is to keep an inventory of every script, watch for changes in behavior, and restrict which page elements each script can read, especially on login and payment forms. A live demo showed a rogue ad script on a checkout page being blocked from reading and sending card details, while the shopper's experience stayed the same.

The closing message is to gain visibility first, then add control, and to prepare for the script-control requirements in PCI DSS version 4. Practitioners should concentrate on the few sensitive pages where scripts matter most instead of trying to police every page at once.