PCI DSS script monitoring is now built into DygDog Pro. The new passive module inventories browser-delivered scripts, reviews Subresource Integrity and Content Security Policy signals, and compares each successful scan with the previous baseline so payment-page owners can investigate unexplained change.

This is an external technical control, not a compliance shortcut. DygDog does not certify PCI DSS compliance, execute page JavaScript or claim that every suspicious signal is Magecart. It gives security and e-commerce teams a bounded, timestamped evidence set they can reconcile with approved releases, vendor changes and their own control procedures.

Evaluate the full PCI DSS script monitoring buyer guide →

What the PCI DSS script monitoring module checks

The module performs seven related checks against the HTML and response headers returned to DygDog:

Script inventory: records sanitised metadata for up to 500 script elements.
Third-party origins: distinguishes scripts delivered by the scanned host from external origins.
SRI presence and syntax: identifies eligible external scripts with missing or malformed integrity metadata.
Cross-origin context: reports cross-origin SRI use without the expected crossorigin attribute.
CSP posture: evaluates the returned Content-Security-Policy, including broad script allowances.
Conservative risk signals: looks for observable patterns such as encoded payloads, payment-field references and outbound browser APIs.
Baseline drift: identifies added, removed or materially changed script entries after a baseline exists.

DygDog fingerprints sanitised inventory entries rather than retaining complete payment-page bodies. Snapshots are scoped to the organisation and exact scanned page URL, with the page classification, script counts, CSP/SRI summaries and observation time stored for review. External entries retain a sanitised URL without query values, use a query-sensitive fingerprint to detect version changes, and track integrity metadata; the module does not download or hash remote script bodies.

How the first baseline and later scans work

The first successful scan has no earlier state to compare. DygDog stores that observation as the initial baseline and clearly reports that drift is not yet available.

On a later successful scan, the module compares the aggregate fingerprint and individual inventory entries with the latest prior baseline. A changed result can reflect an approved deployment, a vendor update, a tag-manager change or an unauthorised modification. It is a triage signal—not automatic proof of compromise.

A sensible response workflow is:

compare the finding with approved releases and vendor notices;
confirm the owner and business purpose of every new script;
review SRI, CSP and other integrity controls;
investigate unexplained changes using controlled browser analysis and relevant logs;
retain the decision and remediation evidence.

See how payment page script monitoring works →

PCI DSS script monitoring and Requirement 6.4.3

PCI DSS Requirement 6.4.3 addresses payment-page scripts loaded and executed in the consumer’s browser. Organisations need to confirm that scripts are authorised, document why each is necessary, maintain an inventory and apply a method that assures integrity.

DygDog contributes the technical inventory and integrity observations. It cannot decide whether a script is authorised or necessary; those are governance decisions the payment-page owner must document. Nor should teams assume SRI is suitable for every vendor script. Dynamically changing resources may require a different integrity-assurance method agreed with the assessor.

PCI DSS script monitoring and Requirement 11.6.1

PCI DSS Requirement 11.6.1 addresses detecting unauthorised changes to payment pages and security-impacting HTTP headers as received by the consumer’s browser. The mechanism operates at least weekly or at a frequency defined by the entity’s targeted risk analysis.

DygDog’s scan-over-scan inventory supports repeat external evaluation. Customers still need to configure an appropriate schedule, assign alert ownership, investigate change and retain evidence in line with their own control design. A Qualified Security Assessor determines whether the complete implementation satisfies an organisation’s obligations.

What SRI and CSP results actually mean

Subresource Integrity allows a browser to compare a fetched resource with cryptographic metadata supplied in the page. It is especially useful for static, versioned third-party assets. According to MDN’s SRI guidance, cross-origin use also depends on the resource passing CORS checks.

CSP answers a different question: which sources and execution patterns may run. A restrictive script-src can reduce exposure, while SRI can prevent a protected static resource from running after its content changes. Neither replaces script inventory, vendor governance or change detection.

DygDog observes the attributes and policy returned with the page. The current module does not download every remote resource and independently recalculate its digest.

Can it detect Magecart or e-skimming?

The module can surface signals that merit e-skimming investigation: a new third-party origin, changed inline script, encoded-code indicators, payment-field references or combinations of outbound browser APIs. CISA describes e-skimming as malicious code introduced to payment-processing pages to capture card data.

Those same code patterns can have legitimate uses. DygDog therefore labels them as risk signals rather than declaring a compromise. Because it does not execute JavaScript, the module may miss payloads delivered only after interaction, runtime tag injection, geofencing or attacker evasion. A clean result is not a guarantee that a site is uncompromised.

Review the Magecart detection scanner scope →

Who should use the new module?

The Pro module is designed for:

e-commerce teams responsible for checkout pages;
agencies maintaining payment flows for multiple customers;
security teams that need an independent external script inventory;
compliance owners assembling evidence for PCI DSS 4.0.1 reviews;
engineering teams that want a clear signal when a browser-side dependency changes.

It works without installing code on the monitored site. That makes deployment simple, but also defines its boundary: runtime-only behaviour belongs in complementary browser-side testing or monitoring.

Start a payment-page script assessment

Run a DygDog scan to establish your current browser-script inventory. Upgrade to Pro for the full Client-Side Supply-Chain Monitor, PCI-mapped findings and scan-over-scan baseline comparison.

Start your DygDog scan →

7 PCI DSS Script Monitoring Checks | DygDog