Your Homepage Passed. Your Checkout Didn't.

When we ran a surface-level scan on a well-known national hospitality brand's homepage, the result came back LOW risk. Clean headers. No suspicious third-party scripts. Nothing alarming. The kind of result that makes a compliance team breathe easy.

Then we ran the deep scan — the same scan that covers checkout, cart, login, account, and payment pages. The result was CRITICAL.

The homepage hadn't lied. It just hadn't told us anything useful.

The Gap Between Surface and Reality

This isn't a rare edge case. It's the rule. Across our scan database of 100,000+ e-commerce and merchant domains, the single most consistent pattern we observe is a significant disconnect between homepage security posture and payment page security posture.

The reason is structural. Homepages are marketing pages. They carry brand content, a nav bar, maybe a hero image. Checkout pages are operational pages — they're where analytics, advertising pixels, tag managers, session recording tools, and payment widgets all converge. Every one of those scripts is a potential vector. And under PCI DSS 4.0.1, every one of them needs to be authorized, inventoried, and integrity-controlled.

The Hospitality Brand: What We Found

The brand in this case study is a well-established national hospitality operator with an active online booking and payment flow. We are not identifying them by name — the findings were identified through passive, publicly observable client-side scanning, and responsible disclosure means protecting their exposure rather than broadcasting it.

Here's how the two scans compared:

The homepage was genuinely low-risk. It had a CSP. Its two external scripts carried SRI integrity hashes. Someone had done the work — on that page. But the payment flow was a completely different environment, and nobody had applied the same standards there.

The Google Tag Manager Problem

The root cause in this case, as in the majority of flagged domains we scan, was Google Tag Manager.

GTM is not inherently malicious. It's a legitimate, widely-used tool for managing marketing and analytics scripts. But its architecture creates a structural compliance problem under PCI DSS 4.0.1 that most merchants don't realize until someone points it out.

In the hospitality brand's case, GTM was loading six additional scripts on the payment pages: an analytics platform, a retargeting pixel, a session recording tool, a live chat widget, a heatmap script, and an A/B testing library. None of them were visible in the page source. All of them were executing on the page where customers entered payment data. None had SRI controls. None could have them.

Two of those six scripts had attached keystroke event listeners to input fields on the payment form — the exact technical signature of a Magecart-style card skimmer.

They weren't skimmers. They were legitimate analytics tools. But from a PCI DSS 4.0.1 perspective, and from the perspective of what the browser was actually doing with customer keystrokes, the distinction is technical — not visible at the network layer, and not something your current monitoring would catch.

Why the March 2025 Deadline Changed Everything

Before March 31, 2025, Requirements 6.4.3 and 11.6.1 were best-practice recommendations. After that date, they became mandatory enforceable controls for every merchant in scope.

That means the self-attestation your team filed last year may accurately reflect your homepage. It may have nothing to do with the actual security state of your payment pages.

What to Do If Your Homepage Passed

A clean homepage result is not bad news — it means someone applied security controls somewhere. But it tells you nothing about your actual PCI DSS 4.0.1 compliance posture. Here's what the findings actually require:

• Scan your payment pages specifically — not your homepage, not a random page. The pages where customers type payment data. That's what 6.4.3 and 11.6.1 are written around.
• Audit every script GTM is loading on checkout pages — get the full list from your GTM container, map it against the pages it fires on, and document business justification for each one. This is your script inventory under 6.3.2.
• Evaluate whether GTM belongs on payment pages at all — many merchants find that removing GTM from checkout pages eliminates the majority of their 6.4.3 findings in a single change.
• Check for keystroke listeners on form fields — a legitimate analytics or session recording tool may be doing exactly what a Magecart skimmer does, from a browser perspective. You need to know.
• Implement a CSP with script-src enforcement on payment pages — this is the single highest-impact remediation action for 11.6.1 and reduces the blast radius of any future compromise.

How CSI Deep Scan Surfaces the Gap

The free scanner at clientsideintel.com scans your homepage — the same way any browser would load it — and returns a surface-level risk assessment. It's a useful starting point. It's not a compliance assessment.

The CSI Deep Scan specifically targets the pages that PCI DSS 4.0.1 is written around:

The deep scan produces a full PDF report — script findings by severity, a complete third-party vendor exposure inventory, Magecart-pattern threat analysis, TLS and header assessment, and a prioritized remediation roadmap. One payment, one scan, delivered to your inbox automatically.

If your last compliance review was based on a homepage scan, you don't yet know your actual posture. The deep scan tells you — before your QSA, your acquirer, or an attacker does.