The checkout is the target, and skimmers ride in on scripts
Magecart is the umbrella name for digital skimming, an attack where criminals inject malicious JavaScript into a payment page so it copies card numbers as shoppers type them and quietly sends the data to a server the attacker controls. The page keeps working, the order still completes, and the theft can run for weeks before anyone spots it. These attacks have climbed steadily because the modern checkout pulls in third party code, from analytics to chat widgets to payment helpers, and compromising any one of those scripts is enough to plant a skimmer on a page you trust.
Two browser side controls do the heavy lifting against this. Subresource Integrity attaches a cryptographic hash to a script tag so the browser refuses to run a file that has been altered on a third party server, which blocks a tampered script before it executes. A Content Security Policy declares which scripts are allowed to run and which destinations the page may send data to, which both limits what a rogue script can do and cuts off the route it would use to exfiltrate cards. Mixed content matters here as well, because an insecure resource loaded onto an otherwise encrypted checkout reopens a gap an attacker can sit in. These are the controls SiteSecurityScore reads on a live page.
The PCI DSS standard now codifies this. Requirement 4 asks you to protect cardholder data in transit with strong cryptography, which on the web means current TLS, valid certificates, HSTS, and no mixed content. Requirement 6.4.3 asks you to authorize the scripts on a payment page and to assure their integrity, with Subresource Integrity as a recognized way to do it, and Requirement 11.6.1 asks you to detect unauthorized changes to those scripts and to security impacting headers on a regular schedule. SiteSecurityScore evidences that web and transport subset and tells you exactly what to fix.
A working checkout can still be leaking cards. A skimmer does not break the page, so functional testing never finds it. Verifying script integrity, locking down your CSP, and watching the page for changes is how you catch the attack that leaves no visible trace.
PCI DSS web requirements mapped to SiteSecurityScore checks
The table maps the PCI DSS requirements that touch your storefront and checkout to what SiteSecurityScore checks. A green check means the scanner directly produces evidence for that area. An amber Partial means it covers part of the area and a process or server side control fills the rest. A red cross means the area sits in your cardholder data environment or your written program, which an ASV scan, a QSA, and your own systems cover.
Payment page script integrity (Requirement 6.4.3)
| Requirement area | SiteSecurityScore |
|---|---|
| Subresource Integrity on external scripts | |
| Content Security Policy directive review | |
| Detection of scripts loaded without integrity hashes | |
| Inventory and written justification of every script | Partial |
Encryption of cardholder data in transit (Requirement 4)
| Requirement area | SiteSecurityScore |
|---|---|
| TLS and SSL configuration and strong protocol checks | |
| Certificate validity and chain verification | |
| Strict Transport Security (HSTS) enforcement | |
| Mixed content detection on checkout pages |
Secure web configuration (Requirement 6)
| Requirement area | SiteSecurityScore |
|---|---|
| Security headers (CSP, X-Frame-Options, Referrer-Policy) | |
| Cookie security (HttpOnly, Secure, SameSite) | |
| CORS and cross-origin configuration | |
| DNS records (SPF, DKIM, DMARC, CAA) |
Change detection on payment pages (Requirement 11.6.1)
| Requirement area | SiteSecurityScore |
|---|---|
| Automated daily scans of scripts and headers | |
| Email alerts when a script or header changes | |
| Historical record of payment page configuration | |
| Server side tamper detection inside your application | Partial |
Cardholder data environment and process controls
| Requirement area | SiteSecurityScore |
|---|---|
| Network segmentation and firewall rules | |
| Stored cardholder data protection at rest | |
| Access control and authentication policies | |
| ASV scanning and full PCI assessment scope |
For the full requirement detail behind these rows, the PCI DSS compliance guide walks through how each requirement maps to a scan, and the full set of frameworks lives on the compliance hub. The cardholder data environment rows are intentionally not covered, since network segmentation, stored data protection, and an ASV scan live inside your infrastructure and your assessment scope.
What SiteSecurityScore checks on a store
A single scan grades the payment page where it counts most, then extends the same checks across your storefront. Every finding comes back with a letter grade and the exact fix.
Script integrity and CSP
Subresource Integrity on external scripts, a directive level review of your Content Security Policy, and detection of scripts loaded without an integrity hash, the core of payment page defense.
Encryption and mixed content
TLS and SSL strength, certificate validity, HSTS, and mixed content detection, so an insecure resource never reopens the checkout to interception.
Headers, cookies, and DNS
The full set of security headers, cookie flags for Secure, HttpOnly, and SameSite, CORS rules, plus SPF, DKIM, DMARC, CAA, and a security.txt contact.
Every finding ships with a copy and paste recommendation, so a failing checkout grade becomes a worklist your team can clear quickly. Export a PDF for your acquirer or QSA, pull results through the REST API into your own dashboards, or scan a logged in cart and checkout flow with the browser extension. The MCP connector exposes the same scan to Claude Code and ChatGPT Codex when a model needs to read your posture.
Daily monitoring catches the script change a skimmer needs
Skimmers slip in between scans. A payment page is only as safe as the last time you looked at it, which is why PCI DSS Requirement 11.6.1 expects change detection on a regular schedule rather than a one time check.
SiteSecurityScore monitoring runs automated scans of your TLS and SSL certificates, security headers, Content Security Policy, the external scripts on your pages, DNS records, and cookies every day. When a script appears, a header is removed, or your configuration drifts, you get an email alert right away. For an online store that is two things at once, an early warning that a skimmer may have landed on the checkout and the continuous record that your payment page change detection control actually operated across the assessment period.
Daily scans of the checkout
Each monitored page is scanned once per day across TLS, headers, CSP, scripts, DNS, and cookies, building the audit trail.
Alerts on script or header change
Get notified the moment a new script appears, a security header drops, or a certificate nears expiry on the payment page.
Scan your checkout for skimming risk
Run a free scan to grade your payment page on script integrity, CSP, TLS, and mixed content, fix what it flags, then turn on daily monitoring so a rogue script never sits on your checkout unnoticed. No account required to start.
Frequently asked questions
What is Magecart and why is it the top web threat for ecommerce?
Magecart is the name for a class of digital skimming attacks where criminals inject malicious JavaScript into a checkout or payment page to silently copy card numbers as shoppers type them and send the data to a server they control. It is the top web threat for online stores because the attack lives entirely in the browser, the page still works normally, and the theft can run for weeks before anyone notices. Attackers often get in by compromising a third party script the page already loads, such as analytics or a chat widget, which is why controlling and verifying every script on the checkout is now central to ecommerce security.
How does SiteSecurityScore help defend a checkout page against skimming?
SiteSecurityScore inspects the controls that stop a skimmer from running and from exfiltrating data. It checks for Subresource Integrity on external scripts, which lets the browser reject a script that has been tampered with, and it reviews your Content Security Policy, which limits which scripts can execute and where the page is allowed to send data. It also flags mixed content, where an insecure resource on an otherwise encrypted page opens a hole, and it grades your TLS and security headers. Each finding comes with a copy and paste fix, so hardening the checkout becomes a concrete worklist.
Which PCI DSS requirements does SiteSecurityScore help evidence?
SiteSecurityScore evidences the PCI DSS requirements that land on the web and transport layer. Requirement 4 asks you to protect cardholder data in transit with strong cryptography, which the scanner checks through TLS strength, certificate validity, HSTS, and mixed content detection. Requirement 6.4.3 asks you to manage and assure the integrity of payment page scripts, which maps to its Subresource Integrity and Content Security Policy checks. The broader Requirement 6 expectation of secure configuration maps to its review of security headers. It does not replace an ASV scan or a full PCI assessment, and it evidences this focused subset confidently.
What is Subresource Integrity and why does PCI DSS 6.4.3 care about it?
Subresource Integrity is a browser feature where you attach a cryptographic hash to a script or stylesheet tag. The browser computes the hash of the file it downloads and refuses to run it if the hash does not match, which means a script that has been swapped or tampered with on a third party server is blocked before it executes. PCI DSS Requirement 6.4.3 expects you to confirm that each script on a payment page is authorized and to assure its integrity, and Subresource Integrity is one of the recognized ways to assure that integrity. SiteSecurityScore checks whether the external scripts on your page carry integrity hashes so you can see where the gaps are.
Does a single scan keep us safe, or do we need to keep watching?
Skimming attacks and third party scripts both change over time, so a one time scan only proves the day you ran it. PCI DSS Requirement 11.6.1 reflects this by expecting you to detect unauthorized changes to payment page scripts and security headers on a regular schedule. SiteSecurityScore monitoring runs automated daily scans of your TLS, headers, CSP, scripts, DNS, and cookies and emails an alert the moment something changes. That gives you both the protection of early detection and the continuous record that a payment page change detection control actually operated.
Is SiteSecurityScore free for an online store to use?
The core scanner is free with no account required. You can run a full scan of your storefront and checkout covering security headers, TLS and SSL, DNS records, Content Security Policy, cookies, CORS, security.txt, mixed content, and Subresource Integrity on external scripts. Paid plans add continuous daily monitoring with email alerts, PDF report exports, REST API access, and higher scan limits, which are the features stores rely on to keep a constant eye on the checkout and to assemble evidence for a PCI assessment.