Website Script Scanner — every script a page runs, and where it sends data

Every script on the page — not just the ones in your HTML

A modern web page assembles itself in the browser. The HTML your server sends names a handful of scripts; those scripts load more — a tag manager publishes analytics and advertising pixels, an A/B testing tool swaps in variants, a chat widget pulls in its own code. None of that appears in your source code or in "view source", which is exactly why it is where attackers like to hide.

This scanner does what a shopper's browser does. Monity's stealth browser — the same engine behind Monity's website monitoring — opens the page, lets every script run, and records each one it executes or requests, including the scripts another script injects after load. Then it reports what it saw: a script inventory, where the page sends data, and the security headers that decide what a script is allowed to do.

What the scan reports

• Script inventory — every external and inline script, first or third party, the vendor behind it when it is a known one, what loaded it (your HTML or another script), and its size.
• Content hashes — a SHA-256 fingerprint of each script exactly as the browser received it, inline scripts included. When code changes, its hash changes; that is the basis of tamper detection.
• Subresource Integrity (SRI) — whether third-party files carry an integrity attribute, so the browser refuses a modified copy.
• Data destinations — every server the page sent requests to: the places data typed into or read from this page can go.
• Frames — embedded frames such as the card fields your payment provider hosts, so you can see whether card data is entered on your page or inside the provider's frame.
• Security headers and injection signals — Content-Security-Policy, HSTS, framing protection, suspicious inline code, eval of encoded strings and javascript: links.

Every table downloads as CSV. The script inventory adds blank columns for a business justification, an owner and an authorization date — the fields an assessor asks for.

How Magecart skimming works — and what a scan can see

"Magecart" is the umbrella name for groups that inject card-skimming code into checkout pages. The skimmer is a small script that reads what a shopper types into the payment form and quietly sends a copy to a server the attacker controls. It gets onto the page through a compromised plugin, a hacked admin account, or — increasingly — a third-party script that the site trusts: the 2018 British Airways breach, which ended in a £20 million fine from the UK's ICO, ran through a modified script on the airline's own site, and in 2024 the polyfill.io domain was bought and used to serve malicious code to more than 100,000 websites that had simply included it.

A scan sees the traces a skimmer cannot avoid leaving in the browser: a script from an origin you did not expect, a familiar script whose content hash suddenly differs, a request to a domain you do not recognise, or card fields that are not inside your payment provider's frame. What a single scan cannot do is prove the page is clean. Skimmers are often conditional — active only on the checkout, only for visitors in certain countries or on mobile, only at night, or only once a card number is typed — so the reliable defence is watching the page continuously and alerting on the first change.

PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1, in plain English

6.4.3 — manage every payment-page script

Every script that is loaded and executed in the customer's browser on a payment page must be managed: there is a method to confirm each script is authorized, a method to assure the integrity of each script, and an inventory of all scripts with a written business or technical justification for why each one is necessary.

11.6.1 — detect changes and tampering

A change- and tamper-detection mechanism must alert personnel to unauthorized modification — including additions, changes and deletions — of the security-impacting HTTP headers and the script contents of payment pages as received by the consumer's browser. It must run at least weekly, or as often as the merchant's targeted risk analysis defines.

Both requirements were best practice until 31 March 2025 and have been mandatory since. For merchants that validate with SAQ A (a fully outsourced payment page or an embedded payment frame), the January 2025 update removed them and added an eligibility criterion instead: confirming that the site is not susceptible to attacks from scripts that could affect the merchant's e-commerce systems.

Where this tool fits: the inventory and its CSV give you the list to justify and authorize, the hashes and SRI column are integrity evidence, and the header checks cover the "security-impacting headers" half of 11.6.1. A one-time scan is evidence of one moment, though, not a detection mechanism — and it is not a PCI assessment. Your QSA or acquirer decides what is sufficient.

Reading your results

• Third-party scripts without SRI. Add integrity and crossorigin="anonymous" to versioned files, or host them yourself. Files that change by design, such as tag manager containers, cannot use SRI — keep them in the inventory and watch their content.
• Scripts injected at runtime. Look at what your tag manager publishes on payment pages and who can publish there. Many teams exclude checkout pages from marketing tags entirely.
• Unfamiliar data destinations. Every domain should map to a vendor you chose. One you cannot explain is worth investigating today.
• No Content-Security-Policy. A CSP limits where scripts may load from and where data may be sent. Start with Content-Security-Policy-Report-Only to learn what your page needs before enforcing it.
• Suspicious inline code. eval on encoded strings is common in legitimate tag snippets but is also how injected code hides. Confirm each one belongs to a vendor you know.

From a one-off scan to change detection

Monity's script & connection watch runs this same scan on your payment pages on a schedule — stepping through to the checkout if it sits behind a basket — and alerts you in Slack, Teams or email when a new script source appears, a third-party script's content changes (your own too, if you ask), data starts going to a new destination, a form or payment frame points somewhere new, or a security header changes. Mark the origins you have approved, and only unexpected ones raise an alert. That is the weekly-or-better detection 11.6.1 describes, with the history to show an assessor.

Related free checks: the cookie scanner shows which of these scripts set cookies or contact trackers before consent, the SSL checker verifies the certificate in front of your checkout, the security headers checker grades CSP, HSTS and the rest in detail, and the SEO audit reviews security headers alongside on-page SEO.