How do you check whether your Content Security Policy meets PCI DSS?

The question tends to arrive in one of two ways. Either an assessment date landed on the calendar and someone upstairs asked “is our CSP even PCI compliant”, or you have read requirement 6.4.3, looked at your script-src, and want to know where you stand before spending money on tooling.

The direct answer has two halves. CentralCSP’s free scanner scores any URL or pasted policy from 0 to 100 on two axes, security and quality, with no account, no email and no usage cap. That tells you how strict the policy is, which is the precondition for everything 6.4.3 and 11.6.1 ask of it. What it does not do is score you “against PCI DSS”: the mapping to the two requirements, and the evidence an assessor will ask to see, live in the PCI DSS module on the Scale plan. Every scanner finding is severity-rated and comes with a fix, and where a real bypass exists you get example exploit code so you can see the problem instead of taking our word for it.

(The scanner used to show a separate PCI DSS Compliance score. Since the September 2026 relaunch it does not, and the rest of this article explains why a number was never the right deliverable anyway.)

What the scanner score tells you about 6.4.3 and 11.6.1

Grading a policy for security is not the same exercise as proving compliance, but the overlap is exactly the subset of policy behavior that the two requirements lean on:

• Script controls that mean something on a payment page. A script-src with a wildcard or a permissive CDN origin cannot support the claim that each script is authorized, which is the core of 6.4.3. That costs security points.
• Unsafe directives. 'unsafe-inline' and 'unsafe-eval' make script authorization a fiction, because anything injected into the page runs. The scanner flags both, plus overly broad source lists.
• Reporting configured. 11.6.1 asks for detection of changes to the page as received by the consumer browser. A policy with no report-uri or report-to has no eyes. The scanner scores that as a gap, not a style point, and the free Reporting API checker tells you whether the wiring behind it actually delivers.
• Known bypasses and typos. JSONP endpoints on allowed origins, misspelled directives that browsers silently ignore. A typo in a directive name is a policy that does nothing, scored accordingly.

Any decent checker flags 'unsafe-inline'. Ours does too, with the exploit next to it. What no scanner does, ours included, is tell a QSA that the policy satisfies a requirement. The score tells you whether the policy is strict enough to be worth building evidence on. Above 80 it is. Below 50 you have a policy project before you have a compliance project.

What a score cannot tell an assessor

A number is not an inventory. Requirement 6.4.3 wants every script on the payment page listed, with a written business justification per script and a method to confirm each one is authorized. No scanner produces business justifications: those are decisions a human records. And 11.6.1 wants change detection running at least every seven days, with alerting and exportable evidence. A point-in-time score, however good, proves the policy looked right on the day you ran it. Nothing more.

We have watched teams present a 90+ score to a QSA as their entire 6.4.3 story. It buys goodwill and roughly five minutes.

Is there a free PCI DSS CSP checker at all?

Report URI publishes free tools, and its policy analyser is genuinely useful for spotting weak directives. It grades security posture without mapping anything to PCI requirements, and Report URI’s actual PCI package (Script Watch and Policy Watch) starts at its Business tier, $197.99 per month as of August 2026. The various standalone CSP checkers floating around do the same job with the same limit: a security grade, sometimes tuned for strict CSP, never a line drawn to 6.4.3 or 11.6.1.

So for the specific question “score my policy against PCI DSS, for free”, the honest answer in September 2026 is that nobody does, and anyone who claims to is selling a security grade with a different label. What the free tools give you is that grade. Ours adds the quality axis, the fixes and the exploit code, and the paid module upstairs turns the same policy into evidence.

When a free score stops being enough

Keep the distinction straight, because we gate this deliberately. The scanner costs nothing, forever, account or not. The PCI DSS module is a different product, on Scale (€349.99/month) and Enterprise: you declare which pages are payment pages, the module inventories their scripts from real traffic, you authorize each one and record a business or technical justification, auto-validation rules keep routine hash rotations out of the pending queue, and a dated change timeline records every script added, changed or removed, with an alert when something appears without a justification. Evidence exports as CSV and PDF, plus an SBOM of the site’s technologies. Justifications and the change ledger are kept until the account is deleted, well past the 90-day window that raw reports live in.

The workflow we recommend, in order: run the scanner today against your payment pages, fix the severity-rated findings (they come with remediation steps, so this is usually an afternoon, not a project), and re-run until the security score reflects a policy you would defend. When the assessment stops being hypothetical, move to Scale and let the module carry the inventory, the justifications and the exports. What the two requirements demand in detail is covered in our breakdown of 6.4.3 and 11.6.1.

The score gets you moving for free. The evidence is what passes the audit.