Script integrity — Magecart & skimming watch
Injected malicious code in third-party scripts is the typical signature of web skimming (Magecart): a third-party script is altered unnoticed and starts reading payment data straight out of the checkout. On a scan, XICTRAQ learns the SHA-256 hash of every external script as a baseline; a cron re-checks these hashes continuously and alerts as soon as a script changes unnoticed. In addition, a scan of a checkout page reports new external form targets — a classic sign of payment data being siphoned off. Available from the Business plan.
# Monitored scripts at a glance
The script-integrity panel of a website shows every learned baseline: the script URL, the serving host, a short hash (SHA-256), the file size in bytes and whether there is currently an open drift alert. Form targets on checkout paths appear as their own entry with the context “form_action”.
# How the watch works
Hash baseline on scan
On every scan, XICTRAQ reads the loaded HTML, finds each external third-party script (hosts identical to the page itself and XICTRAQ-owned scripts are excluded) and fetches its content server-side to compute the SHA-256 hash (`results.html.sri.script_hashes` with URL, host, bytes and SHA-256). For each script this hash is learned as a baseline — the target state: as long as the script delivers exactly this hash, it counts as unchanged. Up to 12 external scripts are fetched per scan (latency cap); each fetch reads at most 512 KB.
Baseline only for your own, verified websites
A baseline is only maintained when the scan belongs to a website in your account that is marked as verified. Quick checks of foreign URLs do not create a baseline — this keeps the watch from being cluttered with third-party scripts. A learned baseline hash is never overwritten automatically; only a deliberate “Acknowledge” advances it. That way the watcher does not swallow a skimmer that stays in the script permanently.
Drift cron re-checks continuously
Every ten minutes a cron job re-fetches the monitored scripts (up to 150 scripts per run, oldest check first) and recomputes the SHA-256 hash. If the hash deviates from the learned baseline, that is a “drift” — the typical signature of a script swapped unnoticed (web skimming). The field contract exposes per entry `drift_count`, the short hash `sha256_short`, `first_seen_at`, `last_seen_at` and `last_hash_at`, so you can trace when something last changed.
Alert via your channels — only once
When a drift is detected, XICTRAQ raises a security alert across all enabled channels (email, Slack, Teams, Discord, Telegram, webhook, browser push — configurable under Settings → Notifications). A drift is alerted only ONCE per entry (field `alerted=true`) until you acknowledge it — no repeated firing on every cron run. Severity depends on the finding: a script-hash change arrives as “warning”, a new external form target on a checkout path as “critical”.
A vanished script is reported too
If a monitored script is no longer reachable during the cron run (no 2xx status, empty body), XICTRAQ reports it once as a warning including the returned status code. A vanished or swapped script is just as suspicious as a pure content change — this too is alerted only once per entry.
Instant re-check on demand
You don't have to wait for the next cron run: the instant re-check re-fetches a website's scripts (up to 60) right away and compares the hashes — handy straight after a planned deployment, to see whether the baseline still matches or needs acknowledging.
Acknowledge = new baseline, dismiss = stop watching
If you updated the script on purpose (e.g. a legitimate deployment), confirm the drift with “Acknowledge”: the current hash is adopted as the new baseline and the alert is closed. With “Dismiss” you stop watching that entry entirely — useful for scripts you no longer want to observe.
# Checkout & form integrity
Skimming almost always targets the payment flow. That's why XICTRAQ watches not only the script hashes but also where forms send their data — especially on checkout paths.
New external form targets
The scan captures the target hosts of all forms (`results.html.sri.form_action_hosts`) and whether a checkout path was detected (`results.html.sri.checkout_path`). If a new, foreign host suddenly appears as a form target — a destination receiving input that wasn't there before — that is a classic sign of payment data being siphoned off. Such entries appear with the context “form_action” and raise the same drift alert. Form targets are captured when the page itself is scanned; the cron only re-fetches the known scripts and does not re-read the page. So scan your checkout page again after every change to the payment flow.
# What a drift alert looks like
Hi Demo Team,
the SHA-256 hash of the following script on www.beispiel-shop.invalid deviates from the learned baseline:
If this was a planned deployment, acknowledge the change as the new baseline. Otherwise inspect the script for injected code right away.
# Relationship to CSP reports & SRI
Script integrity is a standalone monitoring layer and complements two related hardening measures that live in the scan and security modules. The three interlock but solve the problem at different points.
Subresource integrity (SRI) — prevention in the browser
SRI stores a hash (sha384-…) per script in the HTML; if the provider changes the content, the browser blocks loading automatically. That is prevention on your side. The security tab of the scan lists missing SRI protections with their domain. Script integrity adds detection on top: it notices when a script changes — even where SRI is not (yet) set.
CSP reports — what the browser reports
A Content-Security-Policy with report-uri lets browsers report when a resource violates the policy (e.g. a script from a disallowed host). XICTRAQ collects these reports per website. That surfaces violations from real visitor browsers; script integrity in turn checks the content of allowed scripts server-side. Together they cover both disallowed sources and silent content changes.