Your website may be compromised without going down

2,200 third-party scripts. That's the average Cloudflare sees running on a single enterprise domain.

Most companies can name maybe five of them. Google Analytics, sure. Maybe the chat widget. The payment gateway. After that, it gets murky. But every one of those scripts runs in your customer's browser with the same permissions as your own code. They can read forms. They can send data anywhere. And your server never sees it, because your server only knows what happens on the server.

What a quiet compromise looks like

Magecart-style attacks have worked the same way for years. An attacker doesn't need to break into your site. They compromise a library that one of your third-party scripts depends on (a chat widget dependency, an analytics SDK, a payment form module). They add a few lines of JavaScript that silently copies payment form data to an external server.

No downtime. No error pages. The customer pays normally. The only difference is someone else now has their card number and CVV.

The same principle applies to credential theft (modified scripts reading login forms), session hijacking, redirecting selected visitors to phishing pages, or even cryptojacking, where the visitor's browser mines cryptocurrency. The site is slower, but it "works."

In every one of these cases the website looks fine. You find out from a fraud report from your acquiring bank. Or you don't find out at all.

What Cloudflare just opened up

Cloudflare makes basic Client-Side Security available on all plans. Malicious-script detection and related capabilities require the Client-Side Security Advanced add-on.

Assign an alert owner, define escalation rules, and test detection against the scripts on your site. Detection also needs regular review and a response process. Cloudflare Client-Side Security.

The basics that most sites still skip

Even without Cloudflare, two things should be in place on any site that handles logins or payments:

Content Security Policy (CSP), an HTTP header that tells the browser which domains can serve scripts. If a script loads from an unauthorized source, the browser blocks it. The catch is that most sites have no CSP at all. Those that do often use unsafe-inline or unsafe-eval, which defeats the purpose. And CSP isn't set-and-forget, every new widget, every analytics change, every payment integration modifies it.

Subresource Integrity (SRI), a hash attached to external script tags. If the script content changes (say, after a CDN compromise), the browser refuses to run it. Simple, effective for static dependencies.

Start by opening DevTools in your browser, going to the Network tab, and counting how many external domains your site contacts. That number is usually higher than anyone expects.

For the broader cybersecurity picture, we've written about how AI is changing phishing and deepfake attacks and about phishing campaigns currently targeting Slovak companies. On the infrastructure side, CI/CD pipeline security is a related concern.

If your site runs third-party scripts, and it does, it's worth knowing what they're doing. We can run a security check and set up CSP properly.