VikingCloud approves cside for PCI DSS requirement 6.4.3 and 11.6.1

They are the two PCI DSS v4.0.1 requirements that govern payment-page scripts. Requirement 6.4.3 says every script on a payment page must be authorized, inventoried, and integrity-assured, so only approved scripts run. Requirement 11.6.1 requires a change-and-tamper detection mechanism that alerts on unauthorized modifications to the payment page and its HTTP headers. Together they close the client-side gap that skimming and Magecart attacks exploit in the browser.

A QSA, or Qualified Security Assessor, is a firm accredited by the PCI Security Standards Council to audit solutions against the standard. QSA validation matters because most client-side vendors publish a whitepaper they wrote themselves and call it proof. An independent QSA firm instead tests the product and puts its name on the finding. VikingCloud, a global QSA and Mastercard partner, ran that kind of assessment on cside for requirements 6.4.3 and 11.6.1.

Start by confirming the tool covers both halves of the requirements: a live script inventory with authorization and integrity assurance for 6.4.3, and tamper detection with alerting for 11.6.1. Then weigh deployment effort, whether it can block and not only alert, and how it proves compliance. Prioritize vendors with an independent QSA firm's signed evaluation over a self-published whitepaper, since an assessor's finding is what an auditor will actually trust.

Ask for a QSA firm's signed technical evaluation naming their product, not a whitepaper they wrote about themselves. Ask how they detect script changes; cside compares hashed script values in real browser sessions. Ask whether they can block unauthorized scripts or only alert, how they build and maintain the script inventory for 6.4.3, and what deployment requires. cside installs as one first-party script or an agentless scan, with no DNS change and without routing your site traffic.

A self-published whitepaper is marketing the vendor wrote about its own product, so it carries no independent accountability. A QSA-signed evaluation comes from an accredited assessor that tested the solution against the standard and attached its name to the conclusion. For cside, VikingCloud ran a deep technical assessment and found the platform demonstrated capability to meet 6.4.3 and 11.6.1 when deployed correctly. That is the document an auditor will actually weigh.

Both meet the requirements, and the right choice depends on how much you want to touch the page. cside offers a Script Method, one first-party script tag added to the page, and a Scan Method that is agentless. The Script Method gives continuous, real-session coverage of scripts as they execute; the agentless scan suits teams that cannot add a tag. VikingCloud validated cside using hashed values and blocking configurations across this approach for 6.4.3 and 11.6.1.

No. Maintaining the authorized-script inventory that 6.4.3 requires is part of what cside does, so you do not need a standalone inventory product alongside it. cside discovers the scripts running on your payment pages, records them, flags unauthorized changes through hashed value comparison, and can block scripts you have not approved. That covers both the inventory-and-authorization side of 6.4.3 and the change detection 11.6.1 asks for, in one deployment.

cside computes hashed values for each script on your payment pages and watches for any change to those hashes in real browser sessions, so a modified or newly injected script is flagged the moment its payload differs from the approved version. It fetches and analyses third-party scripts on its side before they execute, and can be set to block unauthorized ones. VikingCloud confirmed this hash-based detection during its technical assessment of the platform.

cside can do both. It alerts on script changes for the tamper-detection duty in 11.6.1, and it also supports blocking configurations that stop unauthorized scripts from executing, which is what 6.4.3 expects for authorization control. VikingCloud specifically noted that cside detected script changes using hashed values and blocking configurations, and concluded the solution offers protection against unauthorized script execution when deployed correctly.

VikingCloud ran a deep technical assessment of the cside enterprise platform and tested whether it detected changes to website scripts. It confirmed that cside detected those changes using hashed values and blocking configurations, and demonstrated the capability to meet PCI DSS 6.4.3 and 11.6.1 when deployed correctly. VikingCloud concluded the solution protects against unauthorized script execution and prevents unauthorized changes to web-facing applications. The full report is on the cside trust portal.

You add cside as a single first-party script tag to your pages, or use the agentless Scan Method if you cannot place a tag. There is no DNS change and cside does not route your site traffic. Once live, it inventories the scripts on your payment pages, compares hashed values to catch unauthorized changes, and can block scripts you have not approved. Deploying correctly is the condition VikingCloud attached to its finding, so follow the enterprise setup guidance.

cside uses a usage-based model rather than a flat license, so cost scales with your traffic; there is a free plan to start, and PCI-scoped script control sits in the enterprise offering VikingCloud assessed. Because pricing depends on your page volume and which method you deploy, the accurate number comes from talking to the cside team. cside PCI Shield packages the 6.4.3 and 11.6.1 coverage in one deployment.