Why Do WAFs Miss Browser-Based Script Attacks?
A web application firewall inspects requests arriving at your application. A card skimmer reads the card in the customer's browser and posts it straight to the attacker, so there is nothing for the firewall to inspect. This video explains the server-side blind spot, where each client-side control stops (CSP, Subresource Integrity, external scanning, WAF and script monitoring from real sessions), and the three things to start with. The WAF still protects your application; it just can't see the browser.
Full answer: Client-Side Security and Protection, Explained
Transcript
A WAF inspects requests arriving at your application. A card skimmer reads the card in your customer's browser and posts it straight to the attacker, so that traffic never reaches your servers, and there's nothing for the firewall to inspect. Script Monitoring is one tag that sits where the attack happens, in the browser, and watches every script in every session. Follow the stolen card. The order still goes to your server, through the WAF, and looks normal. The card number takes a second path, from the browser to the attacker. Here's the practical test. If an attack can succeed without a single unusual request reaching your servers, no server-side control can detect it. Card skimming passes that test. Your WAF inspects requests to your application. Your SIEM correlates logs your systems produced. EDR watches your servers. A skimmer runs in a browser you don't own, on a page built from code by several companies. Each control has its place. A CSP restricts which origins load scripts, but a compromised, allowed vendor passes it. Subresource Integrity pins a file, but breaks when a vendor updates. External scanning gets a datacentre view, and targeted payloads don't fire for it. The WAF is still the right tool for attacks aimed at your application. Keep it. It just sees nothing that never reaches your application. Script monitoring from real sessions fills that gap. It observes what actually executed in the browser, for every visitor, including the script's integrity and what it did. It has a limit too. It's a client-side control, and says nothing about your servers, your network or your data at rest. So it's not either-or. Start with three things on your sensitive pages: an inventory of what runs, integrity pinned to the payload, not the address, and an alert to a named person when either changes. That's close to what PCI DSS 6.4.3 & 11.6.1 require. See the browser layer on your own checkout. Script Monitoring is free for 1,000 page views a month, and Pro starts at $99 a month. Start for free at scriptmonitoring.com.