# CSP monitoring for e-commerce: what your checkout actually needs > An online store concentrates its risk on one page (checkout) and one attack (skimming), while its marketing stack injects scripts weekly. What CSP monitoring must deliver: script inventory on payment paths, checkout-scoped alerts in minutes, enforced connect-src, PCI DSS evidence. - Canonical: https://info.centralcsp.com/articles/csp-monitoring-for-ecommerce/ - Published: 2026-08-09 - Language: en - Publisher: CentralCSP (https://centralcsp.com) An online store needs four things from CSP monitoring: a browser-sourced inventory of every script running on payment paths, change alerts scoped to checkout URLs that fire in minutes, an enforced `connect-src` that cuts off exfiltration destinations, and exportable evidence for PCI DSS 6.4.3 and 11.6.1. Everything else a CSP does for you (mixed content, clickjacking) is worth having. Those four are what stand between a skimmer and your customers' card numbers. ## Why an online store's threat model fits on one page Most sites think about XSS in the abstract. E-commerce doesn't get to: the attack that actually empties your incident budget is skimming, and it targets exactly one place. The Magecart playbook is to compromise a script that already runs on your checkout, or quietly add one, and copy card numbers as they are typed. Nothing crashes. Conversion stays flat. We walked through the mechanics in [how a CSP catches a Magecart attack](/articles/catch-magecart-attack-csp/). Meanwhile, the rest of the business is busy widening the attack surface. Google Tag Manager, a Meta pixel, a TikTok pixel, an A/B testing tool, a reviews widget, an affiliate tag, session replay. GTM in particular is remote script injection as a product, handed to the marketing team by design. Every one of those vendors can push new code to your pages without a deploy, and on many storefronts the tag container changes weekly. That is the tension that defines e-commerce CSP work: the page with the highest stakes shares a template, a bundle, or a tag container with the pages that churn the most. A policy built for one breaks under the other. ## Start with a script inventory on payment paths You cannot detect a new script on checkout if you don't know what was there yesterday, and a spreadsheet maintained by hand was stale before it was finished. [CentralCSP's Script Inventory](https://centralcsp.com/en/platform/supply-chain/) builds the list from CSP hash reporting: every visitor's browser reports each script it executes, with origin, full URL and SHA-256 integrity hash. One header, about 5 minutes, no crawler, and critically no agent, because adding a vendor's JavaScript to the page you are protecting is its own supply-chain decision (one several client-side security products ask you to make anyway). Browser-sourced matters more here than elsewhere. A skimmer served from a compromised CDN never touches your servers, and modern skimmers fingerprint headless browsers, so crawlers get the clean version. ## Alerts scoped to checkout, measured in minutes A weekly script review finds a skimmer half a review cycle late, on average. The detection you want is two rules. A new script origin rule on the store, and on the pages you declared as payment pages (`/checkout/*`, your payment iframe's parent pages), the unjustified-script rule: a new script URL or a changed hash that nobody has justified on those pages lands in Slack, Teams, email or a signed webhook on ingest. [Alerting](https://centralcsp.com/en/platform/alerting/) starts on Business (€129.99/mo, unlimited alerts). Start has none, which is fine for building a policy but not for guarding a checkout, and the payment-page rule belongs to the PCI DSS module on Scale (€349.99/mo). The full setup, including delivery into Splunk or PagerDuty, is in [our checkout alerting guide](/articles/checkout-page-new-script-alerts/). The reason those rules survive contact with a marketing team is what they do not fire on. A library moving from `v4.2.1` to `v4.2.2` on the same CDN is not a new origin, and on the payment pages an auto-validation rule for that vendor's routine hash rotation keeps it out of the pending queue. A script from an origin that has never served you code still fires, and anything on a payment page outside a pattern you set still queues. After that filter, what remains is either a tag someone added without telling you, or an incident. ## Enforce connect-src, because the skimmer has to phone home Skimmed card numbers are worthless on your page. They have to leave, usually via `fetch` or an injected form post to a domain you have never heard of. An enforced `connect-src` limited to your own APIs, your PSP and your analytics endpoints turns that exfiltration call into a blocked request and a violation report, even when the malicious code came from an origin your `script-src` trusts. Checkout is the one page where this is cheap: it legitimately talks to very few destinations. Pair it with `form-action` so a hijacked form can't post elsewhere either. ## The PCI DSS part, including the SAQ A trap PCI DSS v4 makes this mandatory, not aspirational: 6.4.3 requires an authorized and justified inventory of every payment page script, 11.6.1 requires tamper detection at least every seven days, and both have been enforced in assessments since April 1, 2025. The inventory and alerts above are the mechanism. The evidence package (justification workflow, per-script business justifications, dated change timeline, CSV and PDF export for your assessor) is on CentralCSP Scale plans (€349.99/mo) and up. Details in [our 6.4.3 and 11.6.1 breakdown](/articles/pci-dss-6-4-3-and-11-6-1-payment-page-requirements/). One nuance catches iframe merchants off guard. The 2025 SAQ A revision removed 6.4.3 and 11.6.1 as line items but added an eligibility criterion: your site must not be susceptible to script attacks. A page that embeds the PSP iframe is still a script attack target (overlay a fake form, swap the iframe), so "we use Stripe" ends the conversation less often than merchants hope. QSA readings vary. We have seen both. ## A policy that survives the marketing calendar The reason most store CSPs die is process, not syntax. Build the policy from real traffic with the [CSP Builder](https://centralcsp.com/en/platform/csp-builder/) over a 1 to 90 day report window, review it value by value, run report-only until the stream is quiet, then enforce. When marketing wants a new tag, the review is one look at the inventory and one policy line, minutes of work. That loop, plus the origin rule from Business and payment-page rules and PCI evidence from Scale, is the whole job. CentralCSP does all of it from one HTTP header, with nothing added to your checkout. ## Frequently asked questions ### Do I need CSP monitoring if my payment form is a Stripe or PSP iframe? Yes, though the scope shrinks. The page embedding the iframe can still be compromised: a skimmer there can overlay a fake form or swap the iframe for its own. The 2025 SAQ A revision reflects this by making eligibility depend on the site not being susceptible to script attacks, so iframe merchants still have to demonstrate their embedding page is protected and monitored. ### How do I keep marketing tags from breaking or bypassing my CSP? Build the policy from real production traffic rather than from a spreadsheet, run it in report-only until the violation stream is quiet, then enforce. For ongoing churn, the new script origin rule ignores a CDN version bump by construction (same origin, no alert), auto-validation rules on your declared payment pages absorb a vendor's routine hash rotations, a genuinely new script still fires, and new-tag requests go through a review that takes minutes, not a change advisory board. ### Which CSP directives matter most for an online store? script-src controls what can execute, and connect-src controls where data can be sent. For a checkout, connect-src is the underrated one: a skimmer that manages to run still has to exfiltrate card numbers somewhere, and an enforced connect-src limited to your PSP and known endpoints blocks that outbound call. Add form-action to stop form hijacking. ### Does CSP monitoring satisfy PCI DSS 6.4.3 and 11.6.1 for an online shop? It maps directly. Requirement 6.4.3 wants an authorized, justified inventory of payment page scripts, and 11.6.1 wants tamper detection running at least every seven days. Browser-sourced inventory plus continuous change alerts cover both mechanisms. The exportable evidence package (justification workflow, change timelines, CSV and PDF export) sits on CentralCSP Scale plans (€349.99/month) and up.