Client-side security, and why your existing tools miss it

Client-side security is the practice of protecting the part of a web application that runs in the visitor's browser, covering the scripts that execute on the page, what those scripts do, and where they send data. It is a distinct discipline from server-side security because the events happen somewhere you do not control and the malicious traffic never reaches your infrastructure. A web application firewall inspects requests arriving at your application; a card skimmer posts stolen data from the customer's browser directly to the attacker's server, so there is nothing for the firewall to inspect. PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 codified two client-side controls as mandatory for payment pages from 31 March 2025.

You will see the term written both as client-side security and client side security, with and without the hyphen, and they mean the same thing. Security tooling grew up around traffic arriving at infrastructure you own. A WAF inspects requests to your application. A SIEM correlates logs your systems produced. An EDR agent watches your servers. Client-side attacks are outside all three, because the relevant events happen in a browser you do not own, on a page assembled from code written by several companies, and the malicious request goes directly from that browser to the attacker.

The exfiltration never touches your server, so a WAF never sees it. The request happens in the visitor's browser, which is the only place it can be observed.

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, which is why it went from a niche technique to a mandatory PCI requirement in one standard revision.

Five kinds of script. First-party scripts served from your own origin, often bundling npm packages, CMS plugins or extensions. Inline scripts written into the HTML itself. Third-party scripts fetched from other domains. Scripts injected at runtime by a tag manager, which can load further scripts of their own. And scripts injected by visitors' browser extensions, which you never shipped at all.

Two properties make this hard to secure. Scripts are dynamic: the same URL can serve different code by browser, device or location, so what one visitor received is no proof of what another did. And most malicious code does not sit in the script you approved. It sits in something that script loads later, under conditions chosen to keep it away from anyone checking.

Inventory first. Not because it is the most exciting control, but because every other decision depends on knowing what is currently executing. Teams that start by writing a CSP without an inventory usually end up with a policy so permissive it allows the thing they were worried about, because the policy was written to avoid breaking a page they could not fully see.