What Changed in ScriptPatrol During Four Months of Open Beta

ScriptPatrol has been in open beta since May 17, 2026. Anyone can sign up and monitor their site for free. Most of our work since then went into checking whether the product behaves on real websites the way we describe it, and fixing the places where it didn't. This is a summary of what changed over the summer.

Numbers from the last 30 days

The figures below cover the 30 days before September 10, 2026. They come from two Czech online shops we monitor, 11 pages in total, among them two carts, a login page and two password-reset pages.

What still sends an email

In late August we counted the change emails the system had sent in the 30 days from July 30 to August 28. There were 69, and none of them was about code our detection had flagged. They described real changes (scripts that were updated, added, removed or reordered), but nobody had to act on any of them.

On August 29 we changed the rule. 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 from the site owner. Examples are code flagged by our detection on any page, a script from a host the page has never used, a weakened security header such as a looser Content-Security-Policy, a new or changed script we could not read in full, and a rejected script that the page still serves. During the first week, while we learn what is normal for the site, only critical findings trigger an alert email.

Everything else is still recorded in the dashboard and counted in the weekly report.

From August 30 to September 10 the same pages produced two change emails. One was about a rejected script that was still being served. The other was about 14 new scripts on a login page and a password-reset page, one of which came from a host those pages had not used before. Why a Good Script Monitor Rarely Emails You explains the rule in more detail.

Every changed script is read to the end

Earlier this year our pattern matching looked only at the first part of each script. That is a known weakness, because malicious code can be added to the end of a large, legitimate library. Now every new or changed script is checked from beginning to end. In the last 30 days that was 9,715 script versions.

If a changed script can't be downloaded completely, that alone is a reason to email the site owner.

What it takes to close a change automatically

Skimmers often imitate well-known scripts. In 2022, Microsoft described attackers disguising their code as Google Analytics and Meta Pixel scripts so that site administrators would take it for harmless code. So a familiar name is never enough for us to close a change.

After a site's first week, a change is closed automatically only when there is evidence behind it, such as who actually serves the script, what its code contains, or confirmation from later scans that a removed script is really gone. When we have decided to trust a script, that decision is checked again every time the script changes, and it is withdrawn as soon as the evidence no longer holds.

On payment and checkout pages, a brand-new script is never approved automatically. And when someone has rejected a script, no automatic process can approve it again.

When a scan can't see the page

Bot protection from Cloudflare, Akamai, F5 and others sometimes shows an automated visitor a challenge page instead of the website. Some of these pages return a normal status code and load scripts of their own, so a scanner can mistake them for the real page. We recognize them by their content, mark the scan as blocked and never use it as the page's baseline. If the site owner had allowed our scanner through the firewall, we also tell them the rule has stopped working.

A page whose address has never responded is paused, checked again once a day and resumed as soon as it answers, and the owner gets an email about it. A page that used to work and then goes down stays monitored. When a Scan Can't See the Page, It Should Say So has the details.

New detection

We added detection for several ways skimmers hide: field names written as character escapes, destinations kept in a table of strings, and encoded payloads that unpack themselves in the browser. We also extended our existing checks for malicious redirects and in-browser crypto mining.

Before release, a new rule is run over more than 3,600 legitimate scripts and must not raise a single alert. The whole process is in How We Test a Detection Rule Before It Reaches Your Site.

Firewall setup and the Shoptet add-on

The setup guide now gives our scanner an identity that can be allowed in a firewall, checks from the dashboard that the rule works, and names the protection that blocked us when it can tell. We also rebuilt the installation and sign-in of our Shoptet add-on to follow Shoptet's developer documentation. The add-on is still in pilot, and we onboard pilot shops ourselves.

What still doesn't work

Some bot protection blocks automated visitors no matter how carefully they behave. In that case the result says the page was blocked, and the fix is to let our scanner through. Integrations for other e-commerce platforms are in development; until they are ready, sites on any platform are monitored from the outside, with nothing to install.