PCI DSS 6.4.3 tools, choosing a payment page script inventory

PCI DSS v4 requirement 6.4.3 asks for an inventory of every script on your payment pages, each one authorized, justified in writing, and checked for integrity. Requirement 11.6.1 asks for a mechanism that detects tampering with those scripts and with the page's HTTP headers, as the customer's browser receives them. Both have been mandatory since 31 March 2025 and both carry into the current standard, v4.0.1.

The tools that cover these requirements observe the payment page in four ways: a JavaScript agent on the page (Feroot, Source Defense, Jscrambler, cside), a proxy for third-party scripts (Evervault), an external scan (Reflectiz, and Cloudflare's sampled variant), or the browser's own reporting (Report URI, CentralCSP). How a tool observes the page decides what it sees, what it adds to your checkout, and what evidence reaches your Qualified Security Assessor (QSA). We build CentralCSP, and the questions below are the ones we designed it to answer. They are also the ones your assessor asks.

CentralCSP builds the inventory from two response headers, with no agent on the payment page. Start a free trial and watch it fill from real checkout traffic, or read how the PCI DSS module works first.

What to ask a payment page script inventory tool

Ask these with your QSA in the room. Each one maps to a clause of 6.4.3 or 11.6.1, and each one separates the deployment models.

Does it see every real session?

11.6.1 names the page as the consumer's browser receives it. A script that loads for one shopper in a thousand, in one country, behind one feature flag, is still in scope. A synthetic scan visits on a schedule with the vendor's browser; a sampled setup sees a fraction of sessions.

CentralCSP uses a capability built into Content Security Policy (CSP) Level 3. The 'report-sha256' keyword asks the browser to hash every script it executes and send a csp-hash report. Every real session reports, first-party and third-party scripts alike, with an integrity hash for same-origin and CORS-enabled scripts. Hash reporting is Chromium-only today; violation reports arrive from every current browser.

What does it add to the checkout?

An agent is one more script on the payment page, loaded first so it can watch the rest. It goes in your inventory with its own justification, and it is a runtime dependency on the vendor. A proxy puts the vendor's CDN in the checkout's critical path.

CentralCSP adds two response headers and nothing on the page. You declare the endpoint with Reporting-Endpoints and reference it from the policy's report-to directive:

Reporting-Endpoints: csp-endpoint="https://MyEndpoint.report.centralcsp.com"

Content-Security-Policy-Report-Only: script-src 'self' 'report-sha256'; report-to csp-endpoint

If the endpoint is unreachable, the checkout is unaffected. The same header is the start of a policy you can later enforce.

How is a justification recorded?

6.4.3 wants a written reason per script. Ask who records it, whether it is timestamped and attributed, and whether it can be rewritten later.

In CentralCSP each script gets a decision, justified or rejected, with a written reason, your name, the timestamp, and the hash it applied to. Decisions land in an append-only ledger, and a revision is a new entry rather than an edit (justifying scripts). Rules approve trusted scripts by URL pattern so review stays short, and a rejection is always a person's decision.

What does the assessor receive?

Ask to see the actual file. Each column should answer a clause of 6.4.3 or 11.6.1 rather than a marketing label.

CentralCSP's evidence export is a ZIP with a PDF report and two complete CSVs: the full inventory, retired scripts included, and the entire change ledger. The report states that it addresses PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1. It is evidence you present; your QSA decides whether it is sufficient.

How does it tell you something changed?

11.6.1 asks for tamper detection at least every seven days. Continuous monitoring from real sessions covers the cadence, but the tool still has to raise the alarm.

CentralCSP alerts on a new script origin and on an unjustified script on a payment page, and a changed hash sends the script back for review. Alerts go to Slack, Microsoft Teams, Google Chat, Telegram, email, or a webhook (alert channels). CentralCSP observes and alerts; the browser, through your CSP, does the blocking.

Where does the data live?

Payment page URLs, script hashes, and session metadata leave your domain. Get the hosting region and the subprocessor list in writing.

CentralCSP hosts report data in the EU on OVH, with a fixed 90-day retention. CentralCSP itself completes PCI DSS SAQ A, and access is governed by SSO, RBAC, MFA, and an audit log.

Can you automate it?

A compliance program lives in tickets, pipelines, and increasingly in an AI assistant. CentralCSP exposes the inventory, the justifications, and the export through a REST API and an MCP server, so a decision can come from a script or an assistant with the same audit trail.

Can you start today?

Enterprise procurement is there when you need it, but a demo gate should not be the only path for a smaller team that takes client-side security seriously. CentralCSP is self-serve: create an account, add the two headers, and the inventory builds while you decide.

How the other tools observe the page

Agent script. Feroot, Source Defense, Jscrambler Webpage Integrity, and cside add a JavaScript agent to the payment page. It runs in real sessions, inventories scripts, and in most of these products also watches what a script does, such as reading form fields; some can block a behavior. That behavior view is the model's strength, and the agent on the checkout is its cost. Jscrambler also describes an agentless monitoring mode.

Proxy. Evervault Page Protection adds a monitoring script and routes third-party script requests through Evervault's CDN, which lets it archive each version and alert on a source change. Scripts hosted on your own domain are not tracked.

External scanning. Reflectiz loads your payment pages in its own sandboxed browser on a schedule, with nothing installed, and flags changes between runs; scripts that load only in specific customer sessions are the question to ask. Cloudflare's client-side security injects a report-only CSP header into a sample of HTML responses passing through its proxy, so it sees sampled sessions, for sites proxied through Cloudflare.

Browser-native reporting. Report URI Script Watch comes from the earlier, collection-first generation of CSP reporting services. It records when each script was first and last seen and alerts when something new appears. Ask how a written justification is recorded and what the assessor receives.

Comparison table

✅ covered, 🟠 partial or to confirm with the vendor, ❌ not offered. Agent script: Feroot, Source Defense, Jscrambler, cside. Proxy: Evervault. External scan: Reflectiz. Sampled header: Cloudflare. Collection-first: Report URI.

Product names belong to their owners. The comparison is based on each vendor's public documentation at the time of writing.

When a rating agency flags the payment page

BitSight, SecurityScorecard, and RiskRecon grade what they see from outside: a missing security header, a Content Security Policy that allows anything. The two headers that build the inventory are also the start of the fix, because a report-only policy fed by real traffic is how you reach an enforced one without breaking the checkout. Run the free security headers scanner on the page, then follow how to fix BitSight CSP findings or how to fix SecurityScorecard CSP findings.

Pick the model, then start

If you need to control script behavior inside the browser, an agent does it, and a vendor script on the checkout is the price. If you cannot touch the page at all, an external scan is the lowest-friction start, with the synthetic-session caveat. If you want every real session, nothing added to the page, and evidence written against the requirement text, browser-native reporting is built for that, and CentralCSP turns it into a review workflow and an export.

CentralCSP helps you meet 6.4.3 and 11.6.1 by producing that evidence; a QSA signs off. Start a free trial, put a report-only policy on your checkout, and the inventory and ledger are ready for the assessor. The PCI DSS module page walks through the rest.

Sources

• PCI Security Standards Council, document library, PCI DSS v4.0.1
• MDN, Content Security Policy guide

Related

• CSP and PCI DSS v4, meeting 6.4.3 and 11.6.1 on payment pages
• PCI DSS v4 client-side security explained for compliance owners
• Build a script inventory with CSP hash reporting