The pages of an online shop load code from many companies, and that code changes all the time. On the two Czech online shops we monitor, 96% of successful scans in the 30 days to September 10, 2026 found at least one script that no longer matched what we had on record for the page. If every one of those changes sent an email, the shop owner would get several a day and would soon stop reading them. Security teams call this alert fatigue.
Where the changes come from
A typical checkout or login page runs code from the shop platform and its theme, plus third-party scripts from analytics services, tag managers, chat, reviews and payment providers. Each of these vendors releases updates on its own schedule, and many publish new builds or rename files without notice.
Over those 30 days, 1,343 of 1,401 successful scans found at least one changed script, and the pages loaded 9,715 script versions we had never seen before. We read each one in full, and our malicious-code detection flagged none.
Attacks still happen. In a Magecart attack, criminals add a web skimmer to the page: code that copies what shoppers type into the checkout form and sends it to a server they control. When that happens, it is a single change among thousands of harmless ones, and the monitor has to pick it out.
What our own alerts looked like
Our first alert rule treated big changes as important changes. In late August we counted the emails it had sent in the 30 days from July 30 to August 28: 69 for those pages. None was about code our detection had flagged. Each described a real change, such as scripts that were updated, added, removed or reordered, and none required any action.
Part of the problem was scoring. If you add up points for every change, twenty harmless updates can end up rated high while a single injected line looks minor. So the rule now asks what kind of change it is.
The new rule went live on August 29. From August 30 to September 10 the same pages produced two change emails. One reported a script that had been rejected but was still loading on the page. The other reported 14 new scripts on a login page and a password-reset page, one of them from a domain those pages had not used before.
Skimmers dressed up as Google Analytics
The easy way to cut noise would be to trust well-known names, and attackers know it. In 2022, Microsoft Threat Intelligence wrote:
“Attackers have also started masquerading as Google Analytics and Meta Pixel (formerly Facebook Pixel) scripts to trick site administrators or developers into thinking they're looking at non-malicious codes, thus evading detection.”
In February 2025, Sucuri described a card skimmer on a Magento store whose code was stored in the site's database and looked like a standard Google Tag Manager and Google Analytics script.
Trust has to come from evidence about the script, such as who actually serves it and what its code contains.
Changes that still send an email
Once a site is past its first week of monitoring, an email goes out when a change looks like an attack or needs a decision only the site owner can make. For example:
- our detection flags code in a newly loaded script as malicious, on any page
- a script loads from an unfamiliar domain the page has never used
- the site weakens a security setting it sends to browsers, such as a looser Content-Security-Policy (which limits where a page can load scripts from) or a removed HSTS header (which keeps browsers on HTTPS)
- a new or changed script could not be read in full
- a script the owner rejected is still loading
- an HTTPS page loads something over unencrypted HTTP, or the site's security certificate is close to expiring
During the first week we are still learning what is normal for the site, so only critical findings send an email.
What happens to the rest
Changes that don't trigger an email are still recorded and shown in the dashboard, and automatic decisions are logged with their reason. The weekly report says how many changes we reviewed and closed that week and how many emails that saved. It also says whether anything is waiting for a decision.
We also report the cases where we couldn't check, such as a script we couldn't read in full or a page address that has never responded. When a Scan Can't See the Page, It Should Say So covers them.
How to tell whether your script change alerts are useful
If you already use a client-side security monitor, look at last month's alerts and count how many of them you acted on. If the answer is close to none, the tool is sending you noise.
If you are choosing a monitor, ask the vendor what it does in two situations. The first is a script that looks like Google Analytics but loads from a domain your page has never used. A tool that trusts familiar names will stay silent about it. The second is a scan that bot protection blocked. If that result looks the same as a clean scan, the dashboard cannot tell you whether anyone actually checked your checkout.
Questions we get
Why not send an alert for every script change?
Because almost every scan finds one. On the two Czech online shops we monitor, 96% of successful scans in the 30 days to September 10, 2026 found a changed script, and none of the new code was flagged as malicious. An email for each of those changes would mean several a day for the shop owner.
If I don't get an email, is the change ignored?
No. Every change is recorded and shown in the dashboard, and the weekly report says how many changes were reviewed and closed and whether anything needs a decision. New script versions are read in full. After a site's first week, a script we could not read in full is reason enough to email you.
Does a well-known vendor name make a script safe?
No. Attackers disguise skimmers as familiar scripts. Microsoft Threat Intelligence described skimmers posing as Google Analytics and Meta Pixel code in 2022, and in 2025 Sucuri found a card skimmer on a Magento store that looked like a standard Google Tag Manager and Google Analytics script. Trust has to come from evidence about the script, such as who actually serves it and what its code contains.
Try ScriptPatrol on your site
The open beta is free, needs no credit card and requires nothing to be installed on your site.