LinkedIn Tag

Pass PCI 4.0.1 While Protecting Your Users

CSPs, JS agents, and crawlers may check the compliance box but they don't truly protect users. See how VikingCloud validated our PCI DSS solution.

Why PCI DSS v4.0.1 Matters

Skimming and formjacking attacks are growing fast. They target the scripts in your customers' browsers, not your servers

6.4.3 and 11.6.1 now mandate a script inventory, real-time monitoring, and alerts for unauthorized changes.

CSPs, crawlers, and agents might tick the compliance box, but attackers easily slip past them.

WITH CSIDE
Reduce audit prep time with weekly PDF reports
Monitor scripts on payment pages with 100% coverage for 6.4.3
Continuous header checks fulfill 11.6.1 without burning IT resources
Protect users from e-skimming, Magecart attacks, and other client-side attacks

How PCI Shield Works

Script Inventory
Scanning...
Script Inventory Full script visibility on all pages (including payment pages for 6.4.3)
payment-form.js
<script>
const form =
document.querySelector('#pay');
form.addEventListener('submit', (e) => {
processPayment(e.data);
});
</script>
Tamper Detection Instant alerts for unauthorized changes (11.6.1) and script modifications
ScriptsExecution
Monitoring
Script Security Visibility into code execution with built-in blocking for malicious scripts
PCI Compliance
Weekly
Jan 8 – Jan 15, 2026
Scripts Verified
47
Changes
3
Threats
0
11.6.1 Compliance100%
6.4.3 Compliance100%
Generating report...
Weekly Reports Automated compliance reports to your inbox.

Choose Your Security Approach

cside is no longer just Gatekeeper. Select the mode that best fits your security needs and technical requirements.

Direct Mode

Easiest

I care about client-side security and I need something that will be easy to explain to the rest of the team.

We check script behaviors in the browser and fetch the scripts on our side. We don't place ourselves in the path of a script unless you explicitly ask us to.

Pros

  • Easiest to implement
  • No performance impact
  • Ability to stop script actions or block by URL, hash, or domain

Cons

  • Not always guaranteed to check the same script payload as the user got - but it's close
  • No performance gains on static or optimizable scripts

Implementation

  • Add our script to your website
  • Still possible to put cside between untrusted scripts and the end user

Operating Model: Allow the script to serve directly for scripts I trust, scripts I don't trust get the full security treatment.

Gatekeeper Mode

Safest

I'm a high value target and need full security control.

We check script behaviors and cside places itself in the middle between the uncontrolled third-party and the end user - only script you didn't tell us not to place ourself in the middle of.

Pros

  • Full visibility
  • Full control
  • Performance increase on some scripts
  • We know that what the user got is what we checked

Cons

  • Hard to explain to your colleagues
  • On highly dynamic scripts latency can be added

Implementation

  • Add our script to your site
  • Flag scripts you trust and don't need cside to serve. By default, we don't proxy some scripts that are incompatible with being served by a different URL

Operating Model: All scripts pass through cside except some.

Scan Mode

Fastest

I don't have the ability to add a script to the website.

cside threat intel gathered by thousands of other websites with combined billions of visitors.

Pros

  • Cheap
  • Fast and easy to setup

Cons

  • Client-side attacks are dynamic, a static scan is by design less likely to spot an attack
  • A highly targeted attack could succeed at avoiding detection

Implementation

  • No script installation required
  • Leverage collective threat intelligence

Operating Model: Static scanning powered by threat intelligence from our network.

Why We Approach It This Way

Unlike modern operating systems, browsers do not have native support for 3rd party security vendors. CSP and SRI only cover so much, so we got to get creative. Most client-side detections using JavaScript in the browser are easy to reverse engineer and circumvent. Unfortunately, too strict client-side detections could break some client-side libraries. What a script for client-side security essentially does is wrap APIs that can be used by bad actors and monitor which scripts use them. The problem is that not every script plays nicely with that. So for that reason, we've taken a much more elaborate approach for the most security conscious users. By combining the detections in the browser with detections on our own engine using our proprietary gate-keeping engine we create a balanced best of all worlds scenario. Balancing detection ability with ease of use with resilience and ultimately giving the customer the ability to choose the approach.

Designed for Teams Facing PCI Challenges

ascii art background

PCI Compliance 4.0.1: Unraveling E-Skimming, Script Security, and PCI DSS Compliance

Watch the complete discussion between cside and VikingCloud experts covering the latest PCI DSS 4.0.1 requirements, e-skimming prevention strategies, and practical implementation guidance for requirements 6.4.3 and 11.6.1.

Recorded: January 25, 2025
Duration: 58:42
2,156 views

Expert Speakers

Simon Wijckmans
Simon Wijckmans
CEO
cside
Alexander Norell
Alexander Norell
Global Security Architect
VikingCloud
2,156 professionals have watched

Topics

In-depth analysis of PCI DSS 4.0.1 requirements 6.4.3 & 11.6.1
Exploration of e-skimming attack vectors and prevention strategies
Guidance on script inventory and authorization processes
Real-world insights into compliance implementation
POWERED BY
vendor logo
vendor logo

Why cside Outperforms Alternatives

Gatekeeper delivers advantages traditional tools can't match.

vs. Crawler-Based Solutions
vs. Content-Security Policy (CSP)
vs. Client-Side Agents
Sees real user behavior, not sanitized crawler views Monitors script payloads, not just sources Undetectable monitoring attackers can't bypass
Catches attacks aimed at specific segments Detects breaches at trusted third-party providers Complete historical script behavior tracking
Detects threats between periodic scans Handles dynamic scripts CSPs can't control Future-proof against evolving techniques
With a Gatekeeper Approach
Complete script visibility: We know exactly what the end user sees.
Immediate threat response: We don't wait for periodic scans.
Historic tracking: We track changes over time for better security insights.
Script-by-script choice of full proxy or capture-only mode.
No performance impact: We ensure a 99.99% SLA with a fail-open design.

Why Leading QSAs Prefer cside

ONLY CSIDE DELIVERS
A PCI-specific dashboard to easily report on 6.4.3 & 11.6.1
Real-time payload inspection before it hits the browser
DOM-level, time-based, and dynamic threat detection

We're one message away

As your partner for web security, we want you to be able to reach us easily. Every customer gets 1:1 access to our team over Slack and Microsoft Teams. We respond in minutes, whether you have a feature request, questions, or ideas.

Shared Slack or Microsoft Teams channel for every customer
Direct access to our security experts
Easy conversational support
Response times in minutes, not days

FAQ

Frequently Asked Questions

View all FAQs

Payment page script management is the focus of 6.4.3. It requires you to authorize every script, ensure script integrity, and keep a complete inventory with a written justification for why each script is important. 11.6.1 mandates you to have continuous monitoring to detect unauthorized changes to HTTP headers and payment page content, including alerts sent to personnel and weekly evaluations.

It is the latest version of the Payment Card Industry Data Security Standard with the aim of protecting cardholder data via strict security monitoring requirements. As long as your business processes, stores, or transmits credit card data, you must comply with these regulations to avoid hefty fines, higher insurance rates, and potential business disruption. This standard is applicable to all merchants, processors, acquirers, and service providers handling payment card data. Depending on your transaction volume and the severity of any breaches, failure to comply can result in fines ranging from thousands to millions of dollars.

Active and constant monitoring is required for 6.4.3, while a weekly monitoring, or at the frequency defined in your organization's targeted risk analysis, is required for 11.6.1. But, since cyberattacks happen in real-time at any moment, continuous monitoring is the best solution.

Penalties vary, but range from $5,000 to $500,000 per incident. This is based on your payment processor and transaction volume. Aside from fines, you may also face increased transaction fees, higher insurance premiums, loss of payment processing privileges, and high costs from data breach remediation and lawsuits. A payment card data breach exceeds $4 million on average when you include forensic investigations, legal fees, customer notifications, and business disruption.

The most comprehensive protection is provided by gatekeeper-based solutions by intercepting and analyzing every script request in real-time. This approach is better than periodical scans or browser-based detections that bad actors can bypass. Visibility into script behaviour, immediate threat blocking capabilities, and accurate compliance reporting that captures all script variations are some of the features that cside's Gatekeeper approach can provide. Viking Cloud has independently audited and approved this method. This gives an additional layer of confidence that your compliance strategy meets the highest industry standards while providing superior security protection.