Stripe CSP Attestation

Stripe CSP Attestation Is Now Required

Step three of your Stripe PCI assessment now has a checkbox for Content Security Policy. There's no “not applicable” option. Deploy a report-only CSP, inventory every script on your payment pages, and back up what you tick.

Start 30-Day Free Trial See what the checkbox actually means
Why This Checkbox Exists

Where Stripe's CSP requirement came from

Requirements 6.4.3 and 11.6.1 exist to catch attacks like Magecart-style skimming, where unauthorised scripts capture payment data directly in the browser. In January 2025, the PCI Security Standards Council revised SAQ A. Those two requirements — payment page script authorisation and change detection — came out of the questionnaire and went into a new eligibility condition instead. To use SAQ A at all, you now have to confirm your payment page is protected from script attacks.

Stripe answered the obvious follow-up question — how do you show that — by adding the checkbox. It's not a new requirement. It's an existing one, made impossible to skip past.

Allowlist vs Policy

Stripe's guidance tells you what Stripe needs. It doesn't tell you what else is running.

Stripe publishes the domains its own scripts need — js.stripe.com, checkout.stripe.com, and so on depending on your integration. Add those to your CSP and Stripe works. That's an allowlist.

It says nothing about the other scripts already on your payment page: the analytics tag, the chat widget, the A/B testing tool, the tag manager that can inject anything at any time. A policy built only from Stripe's list will let Stripe through and leave everything else unaccounted for — because you'd never have shipped a policy that broke your own tools.

The checkbox asks whether you've deployed a CSP. The real question is whether that CSP describes your whole page, not just Stripe's part of it.

Start Free Trial See how Report URI covers this →
What You're Attesting To

PCI DSS 6.4.3 and 11.6.1, in plain terms

6.4.3 — Script authorisation and inventory

Every script on your payment page needs to be known, approved, and documented — not just at your last audit, but continuously.

11.6.1 — Continuous change detection

Any change to your payment page scripts or headers needs to be caught and acted on. Not quarterly. Continuously.

An allowlist covers Stripe. It doesn't cover 6.4.3.

If you're mid-assessment right now, this is the gap between checking the box and being able to back it up if a QSA asks.

What Report URI Does

From checkbox to evidence

Script Watch
Req 6.4.3 — script inventory and change detection

Every script on the payment page, Stripe's and everyone else's

New script, modified script, unauthorised dependency — you know when it happens, not at your next assessment.

Learn more about Script Watch →
CSP Reporting
Req 6.4.3 — real browser evidence

What actually executes, reported by the browsers that ran it

Deploy report-only and every violation becomes a data point — including the ones a static allowlist would never surface, because nothing was ever blocked to reveal them.

Learn more about CSP Reporting →
Data Watch
Req 11.6.1 — behavioural monitoring

Where payment page data is going

Detects when data starts leaving your payment page somewhere it shouldn't. Destinations, anomalies, and a behavioural record — the evidence a QSA actually wants to see.

Learn more about Data Watch →
Policy Watch
Req 11.6.1 — change detection on the control itself

Your policy is only a control while it says what you think it says

Monitors your deployed CSP and alerts you the moment it changes. If your policy drifts from what you authorised, you find out before your next assessment does.

Learn more about Policy Watch →
Start Free Trial
Report-Only Means Nothing Breaks

Deploy this week without touching checkout

The most common objection is “I can't risk blocking something on checkout.” You don't have to. A CSP deployed with Content-Security-Policy-Report-Only blocks nothing. It authorises known-good sources, reports everything outside them, and leaves your page exactly as it is.

Report-only — nothing is blocked
Content-Security-Policy-Report-Only: default-src 'self';
  report-uri https://your-subdomain.report-uri.com/r/d/csp/enforce

No agent to install

No proxy in front of your checkout

No changes to your infrastructure

Site functions normally even if Report URI is unavailable

Get Started

Get your script inventory this week, not at your next assessment

Deploy a report-only policy, and Report URI builds the inventory 6.4.3 asks for from what actually loads on your payment page — not from asking around. Change detection and alerting cover 11.6.1 from day one.

One header. Live in under an hour.

Managing this across multiple properties? Talk to our team →

Where This Fits

What this covers. What it doesn't.

Report URI covers Doesn't replace
Script inventory and change detection Penetration testing
CSP enforcement and violation logging Secure code review
Behavioural data exfiltration monitoring WAF or edge security
Audit-ready evidence generation Vulnerability remediation
FAQ

Frequently asked questions

Yes. Step three of Stripe's PCI assessment includes a checkbox confirming you've deployed a CSP. There's no "not applicable" option, and you can't complete the assessment without ticking it.

A confirmation step added after the PCI Council revised SAQ A in January 2025, requiring merchants to attest their payment page scripts are protected against script-based attacks.

Not on its own. Stripe's guidance is an allowlist for Stripe's own scripts. 6.4.3 requires every script on the page to be authorised, inventoried, and documented — including scripts Stripe has no visibility into.

An allowlist permits one vendor's known sources. A complete policy accounts for every script on the page and is paired with monitoring so new or changed scripts get caught, not assumed safe.

No. Stripe.js must load directly from js.stripe.com. Self-hosting it breaks Stripe's fraud detection updates and can remove your SAQ A eligibility entirely.

A report-only CSP blocks nothing but authorises known sources and logs everything else, satisfying the authorisation intent of 6.4.3 and the change-detection intent of 11.6.1. It's a legitimate first step, with enforcement as the stronger follow-on.

The scripts on a small payment page are the same scripts a skimmer targets on a large one — Magecart doesn't sort by traffic volume. Deployment is one header and a free 30-day trial, so the cost of finding out what's on your page is low regardless of site size.
Proof

Built on data, not claims

Report URI has been collecting CSP violation data since 2015. Founder Scott Helme investigates and writes about live client-side attacks, including Magecart campaigns, using the same reporting pipeline that powers Script Watch and CSP Reporting on this page.

Report URI is also an Associate Participating Organisation of the PCI Security Standards Council — a standing in the standards community. See what that means →

Meeting the new PCI DSS v4.0 requirements was a top priority for us. Report URI gives our team real-time visibility into CSP violations and creates actionable alerts, helping us detect changes quickly and maintain compliance without impacting user experience.

- Erik Segur, Security Tech Lead – REPAY Holdings Corporation

Read the REPAY case study →

Stripe told you a CSP is required.

The only question left is whether yours is a checkbox or a real control.

Start 30-Day Free Trial