Category: Compliance Enforcement

The California Privacy Protection Agency (CPPA) recently issued updates to the California Consumer Privacy Act (CCPA) regulations, which became effective on January 1, 2026, bringing the era of “compliance by documentation” to an end.

For enterprises operating in the modern, composable web where first-party code, third-party services, APIs, and AI agents combine dynamically during live user sessions, these updates introduced rigorous new mandates for cybersecurity audits, risk assessments, and the governance of automated decision-making technology (ADMT).

If there’s one key takeaway from these updates, it’s that policy alone is no longer enough. To remain compliant, businesses must move beyond signaling intent through consent banners and prove technical enforcement at the initial point of data creation in the browser runtime.

What’s Actually Changed?

Under the new rules, companies must proactively evaluate high-risk data activities, back up their security claims with independent audits, and eliminate manipulative user experiences. The regulations also target automated data collection, giving consumers a straightforward way to opt out of tracking and stop algorithmic systems from profiling their behavior.

Here is a closer look at the specific changes:

1. Mandatory Cybersecurity Audits

Starting in 2028 (depending on revenue), businesses meeting the “significant risk” threshold must complete an annual independent cybersecurity audit. These audits must assess the technical effectiveness of the business’s cybersecurity program in protecting personal information from unauthorized access or loss of availability. Crucially, the auditor must be a qualified, objective professional who performs independent testing of actual system evidence—management assertions are no longer sufficient.

2. Data Privacy Risk Assessments

Before initiating any high-risk processing activity, businesses must conduct and document a thorough risk assessment. This report needs to identify the benefits of the processing against the potential negative impacts on consumer privacy, such as unauthorized access, discrimination, or psychological harm. These assessments must be updated at least every three years or whenever there is a material change to the processing activity.

3. The Principle of Symmetry

The CPPA now mandates “symmetry in choice”, meaning that the path to opt-out must be as easy and accessible as the path to opt-in. If your website features a prominent “Accept All” button, it needs to be paired with an equally visible “Decline All” or “Opt-Out” button that requires the same number of steps. Asymmetric designs that nudge users toward data sharing are now classified as violations.

4. Prohibition of Dark Patterns

“Dark patterns” are user interfaces designed to subvert or impair a consumer’s autonomy. The CPPA emphasizes that intent does not matter. If your interface’s effect is to confuse or trick the user into sharing data, it is a violation. Common examples include “confirmshaming,” confusing language, or obstructive consent banners that hide the opt-out option behind multiple clicks.

5. Mandatory Global Privacy Control (GPC) Recognition

A major pillar of the 2026 updates is the requirement to honor Global Privacy Control (GPC) signals. These are universal, machine-readable signals sent by a user’s browser (such as Brave or DuckDuckGo), or via extensions that indicate a preference to opt out of all data selling and sharing.

• Automated Enforcement: Businesses must treat a GPC signal as a valid, binding request to opt out of the sale/sharing of personal information and the use of ADMT for profiling.
• Status Confirmation: Effective in 2026, websites are expected to provide a clear indicator to users (e.g., a “GPC Honored” badge) confirming that their signal has been successfully processed at the technical level.

6. Governance of Automated Decisionmaking Technology (ADMT)

The new regulations target Automated Decisionmaking Technology (ADMT) and Profiling because of their power to evaluate, analyze, or predict a consumer’s behavior, location, or interests.

The CPPA defines ADMT as technology that replaces or substantially replaces human decision-making.

While the law heavily regulates automated profiling in contexts such as location tracking or behavioral analytics, it draws a specific line around ADMT rules: they apply to automated “significant decisions” rather than to standard consumer advertising.

In the modern composable web, profiling happens in the browser. Ad targeting pixels, social media tags, and AI-driven personalization engines aggregate live contextual signals and behavioral patterns in real time. The risk is two-fold:

1. Privacy Exposure: Personal data is often accessed and enriched by third-party scripts before backend safeguards can take effect.
2. Strategic Loss of Control: These technologies often “over-collect,” turning proprietary customer signals into model fuel for external AI platforms.

Businesses using ADMT for “significant decisions” (like hiring, housing, or financial services) or “behavioral profiling” for ad targeting face new obligations:

• Pre-use Notice: Businesses must provide a notice explaining why they use the ADMT, how it works, and the consumer’s right to opt out.
• Opt-out Rights: Consumers generally have the right to opt out of the business’s use of ADMT, requiring the business to stop processing their information using that technology.
• Access Rights: Consumers who do not opt out can request information about how the ADMT worked for them specifically, including the key factors that affected the output.

To prevent standard office software and web infrastructure from accidentally triggering these heavy compliance obligations, the regulations explicitly carve out several everyday technologies. As long as they do not actively replace human decision-making, the following are not considered ADMT:

• Web & Infrastructure Tools: Web hosting, domain registration, networking, caching, website-loading, and data storage.
• Security & Filtering Software: Firewalls, anti-virus, anti-malware, and spam and robocall filtering.
• Basic Administrative & Productivity Software: Spellchecking, calculators, databases, and spreadsheets.

Who Needs to Comply and When?

The updated regulations apply to any business already subject to the CCPA. However, the new requirements for cybersecurity audits and risk assessments specifically target organizations whose processing of personal information presents a “significant risk” to consumer privacy or security.

This includes businesses that:

• Meet specific revenue thresholds and process the personal information of 250,000 or more consumers annually.
• Process the sensitive personal information of 50,000 or more consumers annually.
• Use Automated Decisionmaking Technology (ADMT) for significant decisions or extensive profiling.

Businesses required to complete cybersecurity audits must submit certifications to the CPPA by:

• April 1, 2028, if the business makes over $100 million;
• April 1, 2029, if the business makes between $50 million and $100 million, or
• April 1, 2030, if the business makes less than $50 million.

Businesses subject to risk assessment requirements must begin compliance by January 1, 2026. By April 1, 2028, they must submit to the CPPA:

• An attestation that required risk assessments were completed, and
• A summary of their risk assessment information.

Additionally, Businesses that use ADMT to make significant decisions must comply with the ADMT requirements beginning January 1, 2027.

Enforcement and Investigations

The CPPA maintains a strict supervisory role through several mechanisms:

• Investigations: The agency can initiate investigations based on sworn public complaints or on its own initiative.
• Probable Cause and Audits: The Agency may conduct “probable cause” proceedings to determine if violations occurred. It also has the authority to conduct announced or unannounced audits of any business, service provider, or contractor to ensure compliance with the CCPA.
• Technical Scrutiny: Recent enforcement actions (including multi-million-dollar settlements in 2026) show that regulators are looking for more than written policies; they are comprehensively testing opt-out mechanisms to ensure they work across all devices and services.

The Cost of Non-Compliance: Fines and Penalties

If a business fails to prove compliance, meaning it cannot provide the required risk assessments or demonstrate that its technical controls actually work, the financial consequences are severe:

• $2,663 per violation for unintentional non-compliance.
• $7,988 per violation for intentional violations or those involving the personal information of minors.

(Source)

Beyond administrative fines, the CPPA and the Attorney General can seek:

• Permanent Injunctions: Forcing a business to stop using specific profiling technologies or halting business operations entirely until compliance is proven.
• Statutory Damages: In the event of a data breach, consumers may seek damages ranging from $100 to $750 per incident, creating significant class-action exposure.

The Hidden Risk: Third-Party Script Proliferation

Modern websites are no longer single applications. Rather, they are composed in real-time from a massive ecosystem of external services. This “composable web” relies heavily on third-party scripts to power everything from analytics and advertising pixels to AI-driven chatbots and payment processors.

The scale of this exposure is staggering:

• Average Script Load: Modern checkout pages and high-traffic digital properties routinely load between 30 and 80 third-party scripts.
• Privileged Access: By design, these scripts execute in the browser alongside first-party code and often inherit broad, unmanaged access to the Document Object Model (DOM).

What These Scripts Can Actually Do

Extensive profiling is a major focus of these updates, especially for behavioral advertising, such as that performed by many popular ad-tracking pixels, including Meta, TikTok, and other AI-powered scripts.

Jscrambler’s research into common third-party scripts, including those from major platforms such as Meta and TikTok, highlights the invasive capabilities of overprivileged tags. Because these scripts often operate with “privilege without control,” they can perform actions far beyond their declared purpose:

• Real-Time Form Scraping: Scripts can read sensitive user inputs, such as credentials, personal identifiers, or booking codes, as they are typed, long before a user hits submit.
• Data Enrichment & Profiling: Advertising and social media pixels can capture behavioral signals and interaction patterns to build enriched consumer profiles.
• Unauthorized Data Transmission: Scripts can silently transmit proprietary commercial intelligence (like pricing and product mix) or regulated PII to external global advertising platforms or AI systems for model training.
• Invasive Storage Access: Nearly 90% of cookie and browser storage access on major websites is performed by third-party scripts, enabling them to track users across sessions despite backend protections.

The Vendor Contract Fallacy

Many organizations rely on vendor contracts and due diligence questionnaires to manage these risks. However, these are often insufficient for the modern client-side reality:

• Static vs. Dynamic: Contracts define permitted processing at a single point in time, but scripts update independently and frequently.
• Shadow Tags: Marketing teams or tag managers can inject new code dynamically, bypassing formal security and legal reviews.
• Enforcement Gap: A contract may record intent, but it lacks the technical capability to physically stop a script from over-collecting data at runtime.

The Structural Control Gap: Why Policy is Not Protection

For years, many organizations have relied on CMPs and written policies to manage privacy. Under the new CCPA updates, this approach creates a structural control gap.

A CMP captures a user’s intent to opt out, but it does not technically enforce that intent within the browser runtime where data is actually assembled. Once code and data reach the browser—the “point of creation”—traditional backend protections fade. Third-party scripts, advertising pixels, and AI agents often inherit broad privileges, allowing them to access sensitive data fields and transmit information externally, regardless of the user’s recorded consent.

Under the updated regulations, the CPPA clarifies that a user interface is a “dark pattern” if it subverts or impairs user choice, even if the business did not intend it to do so. If your CMP records an opt-out, but your client-side supply chain continues to collect and share that data at runtime, you are likely in violation.

Best Practices for the New Compliance Reality

To build demonstrable compliance with the latest CCPA/CPRA mandates, organizations must transition from documented intent to technical enforcement. Relying on backend controls is no longer sufficient when data is assembled, enriched, and transmitted directly within the browser runtime.

The following expanded best practices provide a roadmap for operationalizing compliance.

1. Continuous Runtime Discovery & Behavioral Mapping

You can’t govern what you can’t see. Traditional static inventories and manual vendor questionnaires fail to account for the dynamic nature of the “composable web,” where scripts update independently or are injected via tag managers after deployment.

• Inventory Every Vendor: Maintain a real-time, session-level inventory of all third-party and fourth-party scripts, including those from major platforms like Meta and TikTok.
• Behavioral Context: Move beyond basic script lists to map exactly what data elements, such as login fields, personal identifiers, or cookies, each script is accessing in production.
• Detect Behavioral Drift: Monitor for “drift” where a previously approved script suddenly changes its functionality or begins accessing new, sensitive DOM elements.
• Vendor Contract Alignment: Continuously compare live script activity against the data processing permissions defined in your vendor contracts. By monitoring changes in script behavior, permissions, or data exfiltration destinations, you can detect technical contract violations in real time and identify when a vendor begins capturing data they are not legally authorized to access.

2. Enforce Least-Privilege in the Browser

Compliance now requires precise, technical restrictions on what scripts can do once they execute, thereby enforcing the principle of least-privilege in the browser runtime. This is necessary to help ensure privacy preferences are respected and prevent over-privileged third-party scripts from scraping data they don’t need for their primary function.

To meet this technical requirement, it is recommended that mechanisms like “Form Fencing” and “Element Fencing” be deployed. These provide the necessary granular controls, which include:

• Data Fencing: Define granular rules that block scripts from reading specific sensitive fields, such as PII or booking codes, long before a user hits submit.
• Storage & Cookie Fencing: Regulate how third-party tags interact with local browser storage and cookies to prevent unauthorized tracking or cross-session profiling.
• Function Isolation: Isolate scripts, ensuring they only interact with the specific DOM objects and APIs they are authorized to use.

3. Immediate Technical Opt-Out Enforcement

Under CCPA/CPRA, organizations are liable if personal data is shared or sold unintentionally via third-party scripts after a consumer opts out. Procedural opt-outs that rely on backend deletion alone do not prevent real-time client-side harvesting.

• Runtime Blocking: When a consumer triggers an opt-out preference signal, translate that intent into an immediate technical barrier in the browser.
• Prevent Silent Collection: Ensure that scripts from advertising pixels or social media trackers are blocked from capturing behavioral signals the moment the opt-out is recorded.
• Least-Privilege by Context: Automatically adjust script permissions based on the page type, for example, tightening controls on payment or login pages compared to a home page.

4. Network Exfiltration & AI Input Control

Profiling and data sharing risks are ultimately defined by where data is sent. Organizations must govern outbound transmissions at the session level to prevent unauthorized data sharing with external ad-tech or AI systems.

• Destination Whitelisting: Restrict outbound network requests initiated by JavaScript to only approved, verified destinations.
• AI Guardrails: Control exactly what feeds external AI systems or agents before sensitive contextual data, like proprietary pricing or regulated health information, leaves the browser runtime.
• Block Shadow Data Flows: Neutralize unauthorized data exfiltration attempts in real-time without disrupting the legitimate user experience.

5. Demonstrable Audit Trails & Telemetry

Risk assessments and compliance reports are only as valuable as the evidence supporting them. Demonstrable compliance requires verifiable proof that controls were active and effective during live sessions.

• Continuous Evidence: Generate detailed telemetry on every enforcement decision, including blocked behaviors, unauthorized data access attempts, and script changes.
• Audit-Ready Reporting: Produce assessment-ready reports for internal compliance teams and external auditors that prove software integrity and data governance policies were technically enforced.
• Incident Investigation: Use granular runtime event logs to investigate how specific sensitive fields were accessed or where data was transmitted during a suspected event.

Secure the Point of Creation

The days of “set it and forget it” privacy are over. With California leading the charge on regulating personal data collection and automated profiling in the US, the browser is officially your new security perimeter.

The new CCPA requirements represent a shift toward enforceable privacy. By governing execution where digital interactions are formed, enterprises can close the structural control gap, protect customer trust, and meet the high bar set by the CPPA.

Jscrambler’s Client-Side Security Platform provides the missing control layer required for this new era. By governing execution at the point of creation, we help enterprises transform CCPA policy from an aspirational document into a technical reality—ensuring you don’t just “pass” your risk assessment, but actually protect your customers, your brand, and your bottom line.

How to protect your KYC (Know Your Customer) data and applications against unauthorized access and tampering.

It’s time for a reality check regarding know-your-customer, biometric, and user data. 3 in 5 businesses have seen an increase in identity fraud attempts in the last year. Meanwhile, fraud attempts have surged by 80% and identity fraud attempts by 74% over the last three years. Of those fraud attempts, deepfakes made up 6.5%, up a massive 2,000% over the same period. The fraud success rate is holding steady, but there’s no let-up for businesses.

Generative AI and image-creation tools enable criminals to produce forged documents and deepfakes more quickly and effectively than ever before. And serious organized crime groups are crowding out lone-wolf opportunist criminals, increasing the speed and scale of attacks.

How Much is Stolen KYC Data Worth to Criminals?

Criminals steal user data, including KYC and biometric data, to use it or sell it to others. The price for stolen data on dark web forums reflects supply and demand, as well as data quality and the seller’s reputation.

A US social security number may sell for as little as $1. Whereas a credit card number with a 3-digit security code typically fetches $10-60, depending on availability and credit limits. An online banking login sells for $200-1,000, depending on the account balance.

Meanwhile, non-financial data sells for as much, if not more than, financial data. For example, access to Facebook accounts ($45-50), Gmail accounts ($60), passport scans ($100), driver’s license scans ($70-165), and complete medical records ($500+).

How Do Criminals Use Stolen KYC Data?

Stolen personal and financial data can be used to gain unauthorized access to bank and credit card accounts. Criminals then withdraw cash, max out credit cards, or impersonate genuine customers to fraudulently obtain loans or open accounts.

Criminals also commit synthetic identity fraud by blending real and fictitious information to create a synthetic identity to apply for credit, mobile phone contracts, etc. These fake IDs can also be added to accounts as a secondary user to build a credit profile.

Non-financial data can be used for account takeovers (ATO), sophisticated insurance fraud, blackmail, or ransom. One of the most infamous examples of this was when Finland’s largest psychotherapy company, Vastaamo, was breached, and the hacker attempted to blackmail 33,000 patients, whose confidential therapy notes he stole.

Corporate user data, such as high-privilege domain admin or cloud admin credentials, can sell for tens to hundreds of thousands of dollars. This is precisely because criminals can use them to commit potentially lucrative crimes.

The same holds for zero-day exploits, which exploit unknown or unaddressed vulnerabilities in computer hardware, software, or firmware. One of the most famous zero-day exploits was Stuxnet in 2010. This targeted Iran’s nuclear facilities by exploiting four zero-day vulnerabilities.

How Do KYC Data Breaches Affect Individuals?

When a customer’s identity documents, biometric data, or personal records are exposed, the KYC provider is accountable — to regulators, to the businesses it serves, and to the end users whose data it was entrusted to protect.

The downstream impact on verified users from fraudulent account takeovers, phishing attacks, and damaged credit histories quickly becomes a liability for the platform that failed to protect them. Enterprise clients sourcing KYC services expect their provider to absorb that risk, not pass it on. Lost contracts, regulatory penalties under the GDPR, and reputational damage to the provider’s brand can result from a single serious incident.

What is the Business Impact of KYC Data Breaches?

The full cost of a data breach to a business could be massive. These include the direct costs of lost revenue, incident response, fines, and breach notification. No corporate or public sector organization is immune. 94% of banking organizations have been affected by identity fraud. And 34% of fraud cases involve manipulating biometric data to deceive verification systems. This includes physical deceptions, such as fake fingerprints, silicone masks, or 3D models that outsmart biometric sensors.

Biometrics is raising the bar against fraudsters by anchoring identity to something uniquely human. Fingerprints, facial recognition, or voice patterns are harder to replicate compared to a password or card that can be guessed, stolen, or shared.

However, the growth of AI is making deepfake fraud easier and more common. AI-generated faces, voices, and videos increasingly look real and are being deployed to pass ‘liveness detection’ tests in digital KYC and onboarding.

1 in 5 transactions and customer onboarding attempts are fraudulent. That’s according to digital identity provider Signicat, which also found that more than one-fifth (22%) of annual business revenue was impacted by identity fraud and the cost of trying to prevent it. So, the need to keep KYC data secure has become a business imperative with real bottom-line impact.

How Do Businesses Protect Against KYC Data Breaches?

The first step in keeping your customers’ data and business safe is understanding the threats out there. Specifically on the SDK side: script injection, reverse engineering, monkey patching, code tampering, digital skimming, and supply chain attacks in the web browser journey. Forewarned is forearmed when it comes to guiding your threat response.

Start by implementing controls to prevent unauthorized access to sensitive data. For KYC and biometric SaaS providers, this means securing both the server-side infrastructure and the client-side JavaScript SDK that runs in customers’ browsers. Code obfuscation, tamper detection, and runtime protection are essential layers — particularly to defend against script injection, monkey patching, reverse engineering, and virtual camera bypass attacks that specifically target identity verification flows.

Also, conduct regular security assessments, monitoring, and third-party due diligence (for the web browser flow), plus deploy secure code and a comprehensive patching regime. Prevention is better, cheaper, and less painful than a cure when it comes to protecting customer KYC data online.

How Does Jscrambler Help Prevent KYC Data Breaches?

Jscrambler provides a comprehensive client-side protection solution tailored for KYC and biometrics SaaS platforms. Our advanced polymorphic code obfuscation ensures robust security with minimal performance impact, offering a high degree of customization to meet specific needs.

Ensure SDK Protection

The Jscrambler tamper-resistant code thwarts reverse-engineering attempts by obfuscating the code to prevent runtime analysis or modification. Available in real-time, delivering protection at the speed of business.

Secure Higher Conversion

Take advantage of performance-focused customization that balances obfuscation strength with application efficiency. Faster load times and smaller file sizes enhance the onboarding experience.

Get Better Risk Management

Evaluate threats effectively with risk scores. Assigned to tag behaviors for all web pages and user interactions throughout the code lifecycle, so nothing slips through the gaps.

Bolster Customer Trust

Establishing robust security measures is paramount to building trust among users who may be cautious during KYC verification and want to be sure their data sharing is safe.

The Jscrambler Client-Side Security platform protects proprietary application logic, governs third-party and post-deployment supply chain behavior, enforces least-privilege access to sensitive data, controls what feeds external AI systems, and prevents unauthorized transmission during live interactions.

Jscrambler in Action: Securing Biometric Authentication for a Leading Identity Verification Provider

A London-based identity verification provider, one of Europe’s leading biometric vendors, needed to extend certified mobile SDK protection to the web, where DOM tampering and virtual camera bypass attacks threatened to undermine its liveness verification mechanisms. With eIDAS 2.0 compliance also on the line, the company selected Build38’s mobile SDK security tool and Jscrambler’s Code Integrity technology to shield its JavaScript web SDK from runtime manipulation and reverse engineering.

After a proof-of-concept simulating real-world attack scenarios, the results spoke for themselves: robust attack prevention with zero impact on user experience, and a unified security posture across both mobile and web channels.  “We jumped on a call with the Jscrambler team and got very good guidance about what we needed to do. It was easy to set up, easy to fine-tune when it needed fine-tuning, and that was it. Then we let it run,” the Development Lead shared.

The partnership delivered measurable impact across security, performance, and compliance:

1. Unified client-side protection: a single security solution covering both mobile and web channels
2. Reliable at-scale performance: effective against targeted attacks with no impact on user experience
3. SDK security risk mitigation: runtime protection against injection, tampering, and reverse engineering, in compliance with eIDAS 2.0 standards

By partnering with Jscrambler, the company extended its leadership in biometric authentication, ensuring its web channel is as trusted and fraud-resistant as its mobile one. Discover how Jscrambler and Build38 secured biometric authentication end-to-end in the case study.

Jscrambler Client-Side Security Platform

Fraud tactics are evolving fast, and remote identity verification is squarely in the crosshairs. In the upcoming webinar, Jscrambler partners with Cryptomathic to break down how attackers are using video injection, deepfakes, virtual cameras, and session manipulation to bypass IDV controls, and what it takes to stop them. You’ll walk away with practical strategies for securing the full IDV flow across browser and mobile environments, protecting trusted signals, and aligning with standards like OWASP, NIST, and ETS, all without adding friction for legitimate users. Designed for fraud, identity, and security leaders, this session is one you won’t want to miss. Register here.

It’s been a year since PCI DSS requirements 6.4.3 and 11.6.1 became mandatory. By now, most QSAs are well acquainted with what these requirements entail. The challenge isn’t understanding the requirements themselves; it’s assessing whether what a merchant has implemented actually works.

Over the past year, we’ve seen a wide range of approaches in the wild. Some are strong, layered implementations that genuinely improve security. Others are, frankly, checkbox exercises that might satisfy a cursory review but wouldn’t withstand a targeted attack for more than a few seconds. And as we’ve seen from our own research into campaigns like the Blobs to Blockchain attack, the attackers targeting payment pages are sophisticated, well-resourced, and constantly evolving.

In this blog post, we’ll walk through the most common approaches QSAs encounter, examine their strengths and weaknesses, and provide practical guidance on what to look for when assessing whether a merchant’s implementation is effective.

The Spectrum of Approaches

The approaches to meeting 6.4.3 and 11.6.1 span a wide range, from free browser-native features to dedicated client-side security platforms. Each has trade-offs, and understanding those trade-offs is key to assessing whether a merchant’s choice is appropriate for their risk profile.

Content Security Policy (CSP)

Content Security Policy is a browser-native mechanism that allows website operators to define an allowlist of permitted script sources. When a script attempts to load from a source not on that allowlist, the browser blocks it. It’s free, it’s widely supported, and it’s a good foundational control.

The problem is that CSP is more of a prevention mechanism, not a detection mechanism. Unless you’ve built out a reporting infrastructure using report-uri or report-to directives, CSP won’t alert you when something is blocked; it just silently prevents it. And for 11.6.1’s requirement to detect and alert on unauthorized modifications, prevention alone isn’t enough.

In practice, CSP configurations on payment pages are often far too permissive. We regularly see unsafe-inline, unsafe-eval, and overly broad wildcards that undermine the protection CSP is supposed to provide. Maintaining a tight CSP is genuinely difficult; it risks breaking functionality, requires constant tuning as third-party scripts change, and doesn’t protect against compromised allowed sources. If a CDN or third-party provider on your allowlist is compromised, CSP will happily allow the now-malicious script to execute, because it still comes from an “allowed” source.

We also demonstrated in our Blobs to Blockchain research that attackers are using blob: and data: URIs to bypass CSP configurations that don’t explicitly block these sources, and most don’t.

For QSAs, the key questions when assessing a CSP-based approach are: Is there a report-uri or report-to directive configured, and is someone actually monitoring violations? How often is the CSP reviewed and updated? And when was the last time that update broke something?

But what about CSP Level 3?

You might hear that newer CSP directives solve some of these problems. Here’s the reality.

Strict-dynamic, now supported in all modern browsers, including Safari 15.4+, allows trust to propagate from a nonce-validated script to dynamically loaded scripts. In theory, this solves the tag manager problem, nonce your GTM script, and everything it loads is automatically trusted.

The catch is that this is a double-edged sword. You’re effectively delegating your security decisions to whoever controls the tag manager. If the GTM container is compromised or misconfigured to load a malicious script, CSP will happily allow it. You’ve traded one problem, CSP breaking tag managers, for another: CSP trusting whatever tag managers decide to load.

Trusted Types is a more promising development for preventing DOM XSS, as it requires type-safe handling of dangerous sinks like innerHTML. However, it’s currently only supported in Chromium-based browsers (Chrome and Edge), with no support for Firefox or Safari and no clear roadmap for adoption. It’s not a viable cross-browser solution today.

What it boils down to is that CSP Level 3 makes CSP easier to deploy, but doesn’t address the fundamental limitation: CSP validates identity and source, not behavior. A trusted script that turns malicious will still execute.

Subresource Integrity (SRI)

SRI provides a cryptographic guarantee that an external script hasn’t been tampered with. You include a hash of the expected script content in the <script> tag, and the browser refuses to execute the script if its content doesn’t match. On the face of it, this sounds like a strong control for 6.4.3’s integrity requirement.

In practice, SRI has significant limitations. It only works for externally hosted scripts that are served with the correct CORS headers. It breaks whenever a script is legitimately updated, because the hash no longer matches, which means there needs to be a process to authorize the script and update the hash every time a vendor pushes a change. For tag managers, analytics tools, A/B testing scripts, and anything else that changes frequently, SRI is simply impractical.

SRI also provides no alerting mechanism. When a hash doesn’t match, the script fails to load, sometimes silently, sometimes breaking visible functionality. But there’s no alert, no notification, and no audit trail. And it does nothing whatsoever for first-party scripts that are compromised on the server itself.

Most merchants we encounter have given up on SRI for anything beyond a small number of static, rarely-changing scripts. QSAs should check actual SRI coverage and ask about the hash update process. If the answer involves manual updates, ask how frequently those updates actually happen and whether there’s evidence to support that.

Manual Script Inventory and Reviews

Some merchants maintain a spreadsheet or document listing the scripts on their payment pages, with periodic manual reviews to check for changes. This approach meets the letter of 6.4.3’s inventory and authorization requirements, and it forces someone to actually think about what’s running on the payment page, which has some value in itself.

However, a manual inventory is a point-in-time snapshot. It becomes stale the moment it’s completed. It provides no detection capability whatsoever for 11.6.1, and it doesn’t scale. For merchants with multiple payment flows, different technology stacks across regions, or frequent deployments, a manual inventory quickly becomes a maintenance burden that falls behind.

QSAs should ask when the inventory was last updated, and be skeptical of the answer. Ask how changes are detected between reviews. Is there evidence of actual review and investigation, or is it a dusty spreadsheet that gets updated the week before the assessment?

CDN-Based Solutions

Several major CDN and WAF providers now offer client-side security features. For merchants already using one of these CDNs, these solutions appear convenient, with no additional vendor relationship or separate deployment.

The trade-off is that these solutions operate at the CDN or edge layer, which limits their visibility. They can track scripts served through the CDN and, in some cases, offer CSP management and script blocking at the edge. But they have limited visibility into what actually happens inside the browser. Inline scripts, scripts injected into the DOM dynamically, and first-party scripts may not be visible. And data exfiltration that happens purely client-side, via cookies, form manipulation, or localStorage, occurs in the browser, beyond the edge’s line of sight.

There’s also a vendor lock-in consideration. Your client-side security becomes tied to your CDN choice. If you switch CDN providers, you lose your client-side protection and need to start again with a new solution. For global merchants, there’s an additional risk: Akamai, for instance, has been pulling out of certain regions, which means that merchants with a global presence risk finding gaps in coverage or performance.

More broadly, it’s worth considering whether client-side security is a core competency for these vendors or a side feature. CDN/WAF providers have to split their roadmap priority across DDoS protection, bot management, WAF rules, content delivery, and many other features. Client-side security is one small part of their offering, and feature depth and innovation often lag behind pure-play vendors for whom this is the entire focus of the business.

QSAs assessing a CDN-based solution should ask: Does this cover scripts not served through the CDN? Some scripts fail to work when proxied by the CDN, so how are these evaluated? What happens to your client-side security if you change CDN providers? And for global merchants: Are there any regional availability concerns?

Agentless External Scanners

External scanning services periodically visit a merchant’s payment pages from outside infrastructure, analyze the scripts present, and report on any anomalies. They’re easy to deploy, require no code changes, and provide automated monitoring that goes beyond manual reviews.

The weakness of external scanners is their susceptibility to evasion techniques that attackers already use. Attackers routinely employ techniques to avoid detection: geo-targeting skimmers to only activate for users in specific countries or regions; filtering on user-agent strings to detect headless browsers, automated tools, and other non-browser clients; activating malicious code only during specific time windows; targeting only logged-in users; and requiring specific user interactions before the malicious code activates. These techniques aren’t necessarily designed with scanner evasion in mind, but external scanners are vulnerable to them because they see a synthetic view of the payment page, not what real users see.

If an attacker’s evasion techniques prevent the scanner from detecting the malicious code, the scanner returns a clean result, while real users continue to have their card data skimmed.

Detection latency is another consideration. Scanning frequency determines how quickly an attack is detected. Even hourly scans leave a window during which an attack could be active and undetected.

It’s worth noting that not all agentless solutions are created equal. Some vendors, including Jscrambler, offer agentless scanning that goes beyond simple external page visits. Jscrambler’s agentless approach, for example, runs the full Webpage Integrity detection engine from our servers, which means it retains the same behavioral detection capabilities as the agent-based deployment described below. This provides a meaningful step up from basic external scanning and meets the requirements of both 6.4.3 and 11.6.1. That said, agentless scanning, even with a more sophisticated engine behind it, still faces the inherent limitation of not running inside real user sessions. For merchants looking for the broadest possible detection coverage, the agent-based deployment provides visibility into what’s actually happening in customers’ browsers, including the geo-targeted, authentication-gated, and interaction-dependent attacks described above.

For QSAs, the critical question is: How does the implemented solution handle selective evasion? If the vendor can’t articulate how they (or their tool) deal with geo-targeting, user-agent filtering, and authentication-gated attacks, a clean scan result doesn’t necessarily prove the payment page is secure.

MITM/Proxy-Based Inspection

A newer approach used by some vendors involves sitting between the browser and script sources, intercepting and inspecting JavaScript as it’s requested. The idea is to analyze script content in transit before it reaches the browser, without requiring a full JavaScript agent on the page.

This approach can inspect external scripts before delivery, which has some value. However, it raises several questions about detection gaps.

First, what about first-party and inline scripts? If a script is already embedded in the HTML or served from the same origin, it’s not being fetched through the proxy, so does the proxy even see it? For many Magecart attacks, the initial loader is injected directly into the page’s HTML, which would likely bypass this type of inspection entirely.

Second, scripts added dynamically via the DOM, for example, using document.createElement(‘script’), may not pass through the proxy infrastructure if they’re generated and executed client-side.

Third, and perhaps most critically, a significant portion of modern skimming attack behavior happens entirely within the browser. Data exfiltration via cookies, localStorage manipulation, form field hijacking, and WebSocket-based command-and-control communication all occur on the client side, where a proxy sitting between the server and the browser has no visibility. In our Blobs to Blockchain research, the attackers used WebSockets for C2 communication and blobs for in-memory execution; a proxy-based approach would struggle to detect either.

This approach has significant blind spots for attacks that don’t involve fetching an external script, which describes a growing proportion of modern Magecart techniques. And proxy infrastructure introduces its own architectural complexity, latency, and potential points of failure.

QSAs assessing a proxy-based solution should ask: How do you detect modifications to inline scripts? How do you detect data exfiltration via cookies or localStorage? What about scripts loaded dynamically by tag managers after the page has loaded? If there aren’t clear answers to these questions, there are significant detection gaps.

Agent-Based Real User Monitoring

Agent-based solutions place a JavaScript agent directly on the payment page, monitoring real user sessions in real-time. Because the agent runs in the same context as the user’s browser, it sees exactly what the user sees, including inline scripts, dynamically injected scripts, DOM modifications, cookie access, and network requests.

This approach eliminates many of the evasion techniques that plague external scanners. There are no scanner IP addresses to detect, no synthetic user-agents to filter, and no way to geo-fence the monitoring, because the monitoring happens inside real user sessions.

The criticism of agent-based approaches is that, if the agent is implemented naively, attackers could potentially detect, remove, or tamper with it. This is a legitimate concern, but it applies specifically to agents that lack self-protection mechanisms, not to the approach as a whole.

QSAs should ask agent-based vendors a direct question: How is your agent protected from tampering? If there’s no good answer, that’s a genuine gap.

Jscrambler’s Hybrid Approach: Webpage Integrity

Jscrambler’s Webpage Integrity (WPI) takes an agent-based approach but addresses the tampering concern head-on, using the same technology that Jscrambler has built its reputation on: code protection.

The WPI agent is hardened using Jscrambler’s Code Integrity technology, the same obfuscation, anti-tampering, and anti-debugging protections that Jscrambler provides to customers protecting their own JavaScript applications. The agent is delivered polymorphically, meaning its code changes on each deployment, so there’s no static signature for an attacker to identify or target. And RASP (Runtime Application Self-Protection) provides active anti-tampering measures that detect and respond to any attempt to interfere with the agent at runtime.

Beyond self-protection, WPI’s core strength is behavioral monitoring. Rather than simply checking whether a script is “authorized” or matches a known hash, WPI monitors what scripts actually do at runtime. We’ll discuss why this matters in the next section.

Importantly, WPI is designed to complement existing controls, not replace them. For merchants who already have CSP configured, WPI adds a detection layer. For merchants struggling with SRI on dynamic scripts, WPI’s behavioral monitoring fills the gap. For those concerned about scanner evasion, real user monitoring eliminates the issue entirely. And for QSAs needing evidence of continuous monitoring for 11.6.1, WPI provides built-in alerting, dashboards, and an audit trail.

As a pure-play client-side security vendor, this is Jscrambler’s core business, not a side feature bolted onto a CDN or WAF product. That means dedicated R&D, a specialized research team, and a roadmap driven entirely by client-side security needs.

What Does This Script Actually Do?

There’s a deeper question that runs through all of the approaches above, and it’s one that QSAs should keep front of mind: 6.4.3 requires merchants to authorize scripts, but authorization based on what?

Most approaches verify script identity, where it comes from, if the hash matches, and whether it’s on an approved list. But very few verify script behavior, what the script actually does once it’s running in the browser.

Consider a script from a trusted analytics vendor. It’s on the approved list. It’s been there for months. CSP allows it. SRI, if configured, confirms its hash. The manual inventory documents it as “analytics tracking.” Everything checks out.

But what does it actually do? Does it only send analytics data to the vendor’s servers, or does it also read payment form fields? Does it access cookies? Does it make network requests to domains other than the vendor’s own infrastructure?

Now consider what happens when that vendor gets compromised: a supply chain attack. The script still comes from the same approved source. CSP still allows it. The SRI hash will change, but if SRI isn’t configured for that script (and for dynamic scripts, it usually isn’t), nothing flags the change. The manual inventory still lists it as “analytics tracking.” Every identity-based check passes. But the script’s behavior has fundamentally changed.

This isn’t a theoretical concern. The Polyfill.io incident demonstrated exactly this scenario: a legitimate, widely-used CDN was compromised, and scripts from an “authorized” source became malicious. Magecart attackers frequently compromise legitimate third-party scripts rather than injecting entirely new ones. And tag manager abuse, where attackers inject malicious tags through compromised GTM or Adobe Launch accounts, means that the tag manager itself is authorized, but the scripts it loads certainly aren’t.

This is where Jscrambler’s behavioral approach provides a fundamentally different capability. Because WPI monitors what scripts actually do at runtime, it can detect when an “analytics” script starts accessing payment form fields, when a script’s behavior changes from what was observed previously, or when a script begins making unexpected network requests. This closes the “authorized but compromised” gap that identity-based approaches simply can’t address.

For QSAs, this should prompt three questions for any vendor or approach: How do you verify that authorized scripts only do what they claim? If an authorized script gets compromised, how would you detect it? And how do you handle scripts loaded dynamically by tag managers, where the tag manager is authorized but the individual scripts it loads aren’t?

Putting It All Together

To summarise the above, here’s how the approaches compare across the areas that matter most for effective 6.4.3 and 11.6.1 compliance:

Approach	Sees inline JS	Sees DOM-injected	Detects cookie exfil	Detects form hijacking	Behavioural analysis	Evasion-resistant	Vendor focus	CDN-independent
CSP/SRI	N/A (prevention)	Partial	No	No	No	Partial	DIY	Yes
Manual inventory	Point-in-time	No	No	No	No	N/A	DIY	Yes
CDN-based	Limited	No	No	No	Limited	Partial	Bolt-on	No
External scanner	At scan time	At scan time	No	At scan time	No	No	Varies	Yes
MITM/Proxy	No	No	No	No	No	Partial	Pure-play	Yes
Agent (naive)	Yes	Yes	Yes	Yes	Varies	No	Varies	Yes
Jscrambler WPI	Yes	Yes	Yes	Yes	Yes	Yes	Pure-play	Yes

What QSAs Should Be Looking For

Based on the above, here are some practical considerations for QSAs assessing 6.4.3 and 11.6.1 implementations:

Ask questions that test real-world effectiveness, not just compliance posture: “How would you detect an attack that only targets users in Germany?” will tell you far more than “Do you have a script inventory?” Similarly, “What happens if a script on your CDN is compromised?” tests whether the merchant has actually thought through supply chain risk, and “Show me your last three alerts, what triggered them, who responded, and what was the outcome?” reveals whether the monitoring is actually operational or just deployed and forgotten.

Watch for red flags: A CSP-only approach with no violation monitoring. A manual inventory with no change detection mechanism. A scanner-based solution where the vendor can’t explain how they handle evasion techniques. An agent-based solution with no self-protection measures. A CDN-dependent solution for a merchant with global operations. Any of these should prompt further investigation.

Consider whether the merchant’s approach matches their risk profile: A small merchant with a simple, static payment page and a single PSP integration has a different risk profile from a large retailer with multiple payment flows, dozens of third-party scripts, tag managers, A/B testing, and operations across multiple regions. The former might get by with a well-configured CSP and regular manual reviews. The latter almost certainly needs dedicated, real-time behavioral monitoring.

Look for defense in depth: The strongest implementations we see combine multiple approaches: CSP as a preventive baseline, with real-time behavioral monitoring layered on top for detection and alerting. The right combination of controls provides both prevention and detection, which is ultimately what 6.4.3 and 11.6.1, taken together, are driving at.

Conclusion

A year into 6.4.3 and 11.6.1 being mandatory requirements, the market has matured, but confusion persists. Merchants have more options than ever, but not all options are equal, and the gap between “compliant” and “secure” remains significant.

Attackers continue to evolve. They exploit legitimate browser features. They evade scanners, bypass CSP, and compromise trusted third-party scripts. They even use technologies such as blockchain smart contracts for persistence. The approaches that merchants and their QSAs choose need to match this reality.

What it boils down to is this: Does this approach provide broad enough detection to catch the wide variety of techniques that attackers actually use? Attacks can take many forms, from compromised third-party scripts to inline injection, from cookie exfiltration to WebSocket-based C2 communication. An approach that only covers some of these – or worse, can only cover some of these due to technical limitations – leaves gaps that attackers will walk through, not because they’re deliberately evading the solution, but simply because their chosen technique happens to fall outside its line of sight.

Jscrambler’s Webpage Integrity was built to answer that question with a confident yes by monitoring real user sessions, analyzing script behavior rather than just identity, and protecting the monitoring agent itself with the same code-protection technology we’ve been refining for over a decade. For QSAs guiding merchants toward effective compliance, that’s the standard to measure against.

Client-side attacks are one of the most common ways payment data is compromised today. PCI DSS v4 reflects this reality by extending security expectations to the browser and payment pages, where JavaScript executes and sensitive data is exposed.

In our recent webinar, Securing the Browser: How PCI DSS v4 Initiated a Client-Side Protection Journey, Jscrambler’s Product Marketing Manager, Katia Kupidonova, was joined by TJ Goldsmith, PCI Compliance Director at Marriott Vacation Worldwide (MVW), to discuss what this shift means in practice and how organizations can start addressing client-side risk in a structured, sustainable way. 

Below are four important takeaways from the session.

Why PCI DSS v4 forces a rethink of browser runtime security

For years, PCI compliance focused primarily on backend infrastructure: servers, networks, and storage. Meanwhile, attackers quietly shifted their focus to the client side, exploiting JavaScript running in users’ browsers to skim payment data without triggering traditional security controls. PCI DSS v4 closes this gap. It makes clear that if code executes in the browser on a payment page, it is within the security perimeter. MVW is part of a complex business conglomerate that prioritized PCI DSS as part of their client-side protection journey. 

4 Key takeaways: third-party JavaScript is the largest source of client-side risks

Most payment pages rely on a complex ecosystem of third-party scripts for analytics, personalization, and marketing. While these tools enable rapid business growth and require frequent updates, they also introduce risks that are often poorly understood and rarely monitored.

On this point, TJ Goldsmith shared that during the nine-month discovery process to track every page that accepted credit card data, they found shadow IT – “pages and scripts that nobody really owned anymore, but they were still processing credit cards.”

In large organizations like Marriott, with different brands, different codebases, and vendors, marketing teams change things every month. When third-party JavaScript is introduced through decentralized workflows, it becomes the largest and least visible source of client-side risk.

1. Enterprise-scale visibility strengthens security posture

MVW operates across 160 documented card data flows, 15 unique codebases, and multiple brands. With continuous client-side visibility now in place with Jscrambler, MVW’s PCI team can bring real technical data into broader security discussions: “With such little effort on our part, we’re able to bring real technical data to the table and drive improved security posture.” Companies can’t secure what they can’t see. 

2. Granular control without interrupting the business is essential

Rather than blocking third-party scripts outright, which could disrupt marketing, analytics, or even the customer experience, the platform provides fine-grained control to restrict third-party scripts from accessing data. As TJ Goldsmith shared, “You can go all the way down to that one script and decide what you want the tool to do with it.”

Third-party vendors can continue functioning while the sensitive data they attempt to exfiltrate is restricted. This flexibility ensures compliance and protection without impacting performance or customer interactions.

3. Automation eliminates the manual compliance burden

Before selecting a dedicated client-side protection solution, MVW evaluated alternatives such as CDN capabilities and implementing CSP or SRI controls. However, those approaches would have required significant manual oversight and ongoing maintenance.

As Goldsmith explained, compliance is managed internally by a very small team: “Even though we’re a relatively large company, we do self-assess PCI compliance here. [Myself] and my little team manage the compliance work for all six entities simultaneously.”

Manually maintaining CSP policies, validating script hashes, and reviewing script inventories across that scale would have created an unsustainable compliance burden. Instead of adding operational complexity, MVW needed automation that satisfied PCI DSS v4 requirements without requiring constant manual intervention.

4. Client-side protection is a journey

PCI DSS v4 can serve as a practical starting point for client-side protection. The standard provides a clear framework that encourages greater visibility, continuous monitoring, stronger governance, and closer collaboration across security, compliance, and development teams. Organizations that use PCI DSS v4 as a catalyst for these efforts are better positioned not only to meet compliance requirements but also to meaningfully reduce real-world risk. Regardless of where an organization stands today, it’s never too late to begin implementing more resilient client-side security.

—

As discussed during the webinar, MVW’s client-side protection journey highlights what’s possible when organizations move beyond compliance and focus on securing what actually runs in the browser.

By working with Jscrambler, MVW gained continuous visibility into client-side JavaScript, detected unexpected and risky script behavior in real time, and established controls aligned with PCI DSS v4 requirements, without disrupting development or marketing teams. This approach allowed MVW to reduce client-side risk while maintaining the agility required by modern digital businesses.

The same challenges MVW faced are shared by many organizations today: growing reliance on third-party scripts, limited browser visibility, and increasing pressure to demonstrate compliance with standards like PCI DSS v4. Companies are looking to reduce tooling and improve efficiency with easy-to-use, straightforward solutions.

Jscrambler helps address these challenges by providing a scalable, runtime approach to client-side protection that supports security, compliance, and business teams alike.

For organizations beginning or advancing their client-side protection journey, Jscrambler offers a practical path forward: from visibility and monitoring to governance and real-time protection, always with seamless integration and constant customer support, focused on securing the browser, where modern attacks occur.

Today marks one of the most essential milestones in Jscrambler’s history — and in the evolution of client-side security.

We’re proud to announce that the Jscrambler PCI DSS Solution is the first solution to include a built-in AI Assistant designed to help organizations meet the new PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1.

For the first time, teams can rely on an AI Assistant to support them in understanding, analyzing, and making informed authorization decisions about every script running on their payment pages. This is a fundamental shift in how merchants and service providers can achieve and maintain compliance while dramatically improving security assurance and analyst confidence.

The new gold standard for script authorization

Why do we call it the gold standard?

Because it gives security teams a new, higher standard for managing scripts under PCI DSS.

Until now, script authorization has been a manual, time-consuming process — requiring analysts to navigate countless vendor domains, behaviors, and updates with limited context.

The new AI Assistant transforms that experience by adding four things:

1. AI Insights – The model distills Jscrambler’s intelligence about each script vendor, generating a concise, contextual summary of its purpose, behavior, and reputation.
   
   

2. Actionable Recommendations – Each script comes with a clear recommendation of what to do:

   • ✅ Authorize the script

   • ⚠️ Authorize with restrictions

   • ❌ Reject the script
     

3. Instant Justifications – Generate quick and accurate justification text for faster, consistent, and high-quality compliance workflows with a greater long-term impact.

4. Interactive AI Chat – Users can instantly ask:
   

   • “Why is this script considered risky?”

   • “Is this domain linked to known malicious activity?”

   • “What has changed in the behavior of this script recently?”
     and get quick, contextual answers — directly in the dashboard.
     
     

Together, these capabilities make the authorization process faster, smarter, and more defensible — turning a compliance obligation into a structured, confident decision workflow.

Decision empowerment, not automation

The AI Assistant is an opt-in add-on to our PCI DSS solution. Those who prefer the traditional, manual workflow can continue using it as is. When enabled, it never takes action on its own. It doesn’t approve or reject scripts autonomously.

From there, the benefits quickly multiply:

• Improved efficacy through risk-based analysis: By understanding behavioral patterns and correlating them with Jscrambler’s intelligence database, the AI Assistant prioritizes what truly matters — allowing analysts to focus their time on the scripts that pose genuine risk.

• Reduced manual effort and fatigue: Instead of manually cross-referencing vendor data, behavioral logs, and historical context, the AI Assistant consolidates that work into a single, explainable insight. This drastically reduces the time spent on repetitive reviews.

• Improved cost and operational efficiency: Faster, more accurate authorizations mean leaner security operations and shorter compliance cycles — without expanding headcount.

• Built on Jscrambler’s foundational expertise: Every recommendation is grounded in over a decade of client-side security research and telemetry. The Assistant doesn’t just analyze data; it draws on institutional knowledge that’s been proven in real-world attacks and compliance audits.

Its role is to empower users — giving them the clarity and confidence to make the right decision in the shortest amount of time possible.

In PCI DSS 6.4.3/11.6.1 workflows, accountability must stay human, and our AI respects that boundary. It helps users synthesize data, surface patterns, and navigate complex risk trade-offs — but the final call remains yours.

Guardrails against AI risks

We built this Assistant with the same rigor we apply to every security control — designed for trust, explainability, and user empowerment.

1. Mitigating Hallucinations

AI models can sometimes misinterpret data or fill in gaps with guesses. We’ve taken multiple measures to reduce that risk:

• Strict Context Control: The model only accesses verified, scoped data relevant to the script under analysis.

• Evidence-Based Grounding: All insights are validated against Jscrambler’s behavioral telemetry, known vendor profiles, and historical data.

• Transparency in Confidence: When uncertainty exists, the Assistant flags it clearly and suggests manual review.
  
  

2. Protecting Your Data and Autonomy

• Prompt Injection Defense: The Assistant is shielded against malicious or manipulative prompts that could attempt to alter its behavior or extract sensitive information. We enforce strict input sanitization, contextual isolation, and output validation to ensure that no injected content can influence system integrity or access protected data.
  

• Private and Secure Processing: No private or sensitive customer data is ever sent to our AI provider. And data that it is sent, is not used in training, as enforced by signed contractual agreements.
  

• Full User Control: The feature is opt-in and can be disabled at any time. The Assistant never modifies configurations or acts independently.
  
  

3. Continuous Learning and Human Feedback

• Analyst Feedback Loops: Each interaction helps refine recommendations and improve contextual accuracy over time.
  

• Explainable Output: Every recommendation is accompanied by supporting rationale — so you can understand, trust, and defend each decision.
  

We’ve treated this as a security product — not a novelty — ensuring that AI adds trust and speed, not noise or risk.

A new chapter for client-side security

This release cements Jscrambler’s position as the innovation leader in client-side protection. It’s the next logical step in our mission: to make webpage integrity and PCI DSS compliance both effective and effortless.

By combining Jscrambler’s deep script telemetry with explainable AI, we’re giving every analyst — from merchants to PSPs — the power to act faster, decide smarter, and stay compliant with confidence.

And this is just the beginning. Expect more AI-assisted capabilities across the Jscrambler platform — always grounded in trust, transparency, and security.

Originally posted in January 2025

In light of the upcoming PCI DSS future-dated requirements deadline (March 31st, 2025), many companies are evaluating tools and solutions to help them comply with the PCI DSS v4 anti-skimming requirements 6.4.3 and 11.6.1.

This article discusses Jscrambler’s new white paper, “The Hidden Costs of CSP/SRI for PCI DSS v4 Web Skimming Requirements”, which explores the benefits and caveats of the popular CSP (Content Security Policy) approach. While it might initially seem inexpensive, the financial and operational burden of using it for PCI DSS compliance is often much higher than anticipated. 

What are CSP and SRI?

Content Security Policy (CSP) is a W3C browser security standard that provides an extra layer of security in detecting and mitigating attacks that can result in data theft, site defacement, and malware distribution, among others. CSP, supported by all modern web browsers, offers a standardized way for website owners to limit the sources of their content(JavaScript, CSS, etc) that are allowed on their website. Essentially, CSP communicates its policies to the browser through an HTTP response header or HTML meta elements that browsers then enforce to strengthen security. CSP and SRI (Subresource Integrity) can be leveraged in conjunction with other processes to meet PCI DSS v4 anti-skimming requirements.

SRI is a security feature that allows browsers to ensure that loaded resources (such as those from a third-party domain) have not been tampered with. It achieves this by enabling you to specify a cryptographic hash that the resource must match.

What is needed to meet requirements 6.4.3 and 11.6.1?

In simple terms, PCI DSS v4 requirements 6.4.3 and 11.6.1 come down to the following: 

Requirement 6.4.3 

– Maintain an inventory of all scripts.

– Implement a method to confirm that each script is authorized.

– Document written justifications for the necessity of each script (business or technical reasons).

– Assure the integrity of each script.

Requirement 11.6.1 demands the deployment of a tamper-detection mechanism to:

– Alert personnel to unauthorized modifications to:

  – Security-impacting HTTP headers.

  – Script content as received by the consumer browser during the payment process (e.g., DOM-level).

The requirements’ goal is to reduce the risks associated with web skimming on payment pages or pages hosting the payment page (e.g. iframing them). By meeting the requirements, merchants become aware of scripts running on their payment pages. For more information on what kinds of data third-party vendors can access, check out this recent market research about the perils of third-party tags.

Key Highlights of a CSP/SRI-based Approach

How CSP/SRI help meet the requirements 

Even though there are multiple benefits of the Content Security Policy related to its main functions in preventing code injection, clickjacking, and other client-side vulnerabilities, this section will explore only what helps meeting  with PCI DSS v4 anti-skimming requirements.

Requirement 6.4.3

• Inventory of all scripts:

One technique that uses CSP to create a report is to roll out a very restrictive CSP policy in report-only mode. It essentially generates a CSP report per script that is loaded on the pages where the CSP policy is used. The sum of all reports will result in an up-to-date list of scripts (URLs). Of course, a URL doesn’t automatically say what the scripts are and what they do. That’s up to the organization to meet the requirements to determine.

• Script authorization:

CSP can enforce script authorization by allow-listing script URLs or by specifying script hashes in the script-src directive. Alternatively, SRI can validate (enforce authorization) a script’s integrity using precomputed hashes.

• Script integrity assurance:

SRI can ensure the integrity of scripts loaded with the integrity attribute.

CSP can allow-list specific URLs, which might prevent unauthorized scripts from being loaded, but it can’t assure the integrity of authorized scripts. To assure it, organizations can indicate script hashes, as mentioned before.

Requirement 11.6.1

• Script change detection:

CSP can alert when scripts deviate from authorized hashes, provided these hashes are included in the script-src directive.

The CSP and SRI are mentioned in the guidance column of the standard by the PCI Security Standards Council and are considered suitable to meet the requirements for PCI DSS v4 requirements 6.4.3 and 11.6.1. However, the PCI Security Standards Council does not provide advice or recommendations on how to implement the CSP and/or SRI. It is up to the assessed organization to determine how to meet these requirements and to complement them with other processes, as it’s not possible to meet all the demands of the two requirements with just CSP and/or SRI. The additional work necessary to meet the requirements completely can result in significant operational efforts, as discussed below.

Gaps and Challenges

At first glance, using CSP and/or SRI with additional processes might seem like a cost-effective approach to meeting PCI DSS v4’s anti-skimming requirements. However, a closer look at the practical implementation reveals significant hidden costs, both in terms of resources and operational overhead. The adoption of the CSP and/or SRI comes with significant operational, performance, and security challenges that have measurable cost impacts. 

Operational challenges

Initially, using CSP and/or SRI to meet PCI DSS v4’s anti-skimming requirements may seem cost-effective, but the practical implementation reveals significant hidden costs in resources and operational complexity. 

Firstly, maintaining a script inventory using CSP generates unmanageable report volumes, especially with dynamically changing third-party hosted scripts. Secondly, script authorization involves time-consuming risk assessments and frequent updates for third-party scripts, while manual documentation for authorized scripts adds further ongoing burden. Ensuring script integrity requires constant hash maintenance to avoid functionality breaks.

Maintaining hashes is not enough though, scripts have to be verified for the potential presence of skimming code, which CSP or SRI on their own do not provide. Having to do it constantly is labor-intensive and may result in alert fatigue, leading operational teams to approve scripts without the proper validation. Furthermore, monitoring HTTP headers necessitates separate systems. 

These processes demand substantial staff time, resulting in high operational expenditures (OPEX) that often exceed any initial cost savings, diverting resources from strategic priorities and risking compliance failure.

Security challenges

Security challenges also persist despite the implementation of CSP and/or SRI. While CSP and SRI enhance web security, their limitations make them insufficient for fully addressing PCI DSS v4’s anti-skimming requirements.

CSP’s URL allow-listing is widely known to be vulnerable to bypasses and cannot fully prevent compromised authorized scripts from executing malicious logic. Hash-based integrity enforcement is more secure but impractical for frequently changing or dynamically updated third-party scripts, creating blind spots in protection.

CSP and SRI also lack mechanisms to monitor or alert on HTTP header changes, therefore they do not contribute to meeting requirement 11.6.1. Additionally, CSP’s static configurations struggle to manage the dynamic nature of modern web ecosystems, requiring significant manual oversight prone to delays and errors. These shortcomings highlight the need for more comprehensive, automated solutions to effectively mitigate web skimming risks.

Website performance challenges

From a performance standpoint, CSPs can inadvertently disrupt website functionality. Their lack of granularity means scripts are either fully allowed or completely blocked.

SRI silently blocks mismatched hashed scripts, which could happen accidentally due to failure to timely update the hash signature. These facts increase the likelihood of breaking applications, which may be hard to detect quickly. Such issues may contribute to downtime, with severe financial repercussions—companies stand to lose anywhere between $145,000 and $540,000 per hour of downtime due to lost revenue, depending on the industry your organization is in. Additionally, the inability to fine-tune script permissions poses ongoing risks to operational efficiency and user experience.

Brief comparison between CSP/SRI, Agentless tools, and Agent-Based Solutions 

There are three main types of solutions accepted to give the merchants a compliance status: CSP and/or SRI, Website monitoring (Agentless monitoring and/or Agent-based solutions), and Proxy-Based solutions.

All three types of solutions are adequate and acceptable for PCI DSS v4 compliance. However, there are some differences. In the Jscrambler table below, you can see that in some aspects, certain solutions go further as they are specifically built for the PCI DSS v4 compliance, unlike the CSP and/or SRI.

Choosing a vendor-based solution over implementing CSP and/or SRI for PCI DSS v4 compliance offers a more sustainable, efficient, and cost-effective approach to mitigating web skimming risks. Vendor solutions provide comprehensive out-of-the-box compliance for all requirements, eliminating gaps left by CSP and/or SRI. Automation significantly reduces operational burdens by dynamically managing script inventories, logging justifications, and analyzing changes, freeing teams from repetitive tasks. Advanced technologies, such as behavioral analysis and runtime monitoring, enhance risk mitigation by adapting to threats in real-time.

Vendors can also manage compliance operations through services like Delegated Compliance, offered by Jscrambler, further simplifying management. While requiring upfront investment, vendor solutions reduce long-term operational expenses and offer predictable costs, ensuring scalability. With rapid deployment capabilities, vendors enable faster and more reliable compliance ahead of the April 1st, 2025 deadline.

Learn more from the white paper

To learn more about the efforts needed to make the CSP and/or SRI work properly, get the full version of the white paper “The Hidden Costs of CSP/SRI for PCI DSS v4 Web Skimming Requirements”.

Originally published in June 2024

PCI DSS 4.0.1 was released on June 11th, 2024.

It’s a limited revision that aims to correct small typographical errors and make clarifications. However, sometimes such clarifications translate into more than significant changes to a requirement. This article covers the main changes in PCI DSS 4.0.1 compared to the previous version. In version 4.0.1, some changes affect both requirements 6.4.3 and 11.6.1. 

Changes brought by PCI DSS v4.0.1

PCI DSS Requirement 6.4.3

What’s necessary?

In PCI DSS 4.0, guidance was given that necessary in the context of a script in the payment page meant “needed for the functionality of the payment page to accept a payment transaction”. In 4.0.1, this has changed to “a business or technical justification as to why each is necessary” as part of the Defined Approach Requirement. Moving this from the Guidance to the requirement itself makes it normative (i.e., what you need to do to fulfill the requirement, rather than just informative).

Jscrambler’s Recommendation

This is a significant weakening of the requirement, but it reflects that the business often needs scripts on the payment page that are not necessary for making a payment. Jscrambler’s advice is to minimize the number of scripts on the page to reduce the attack surface, and to use Jscrambler’s Webpage Integrity (WPI) to secure and manage them.

When to authorize?

It’s impossible to authorize changes to third-party scripts before they are made. None of the third-party script providers will include you in their change control process. And even internally, someone using a tag manager will add a script to your payment page without anyone else’s knowledge.

The practicalities of managing third-party scripts have now been reflected in the guidance, with the following added.

“Where it is impractical for such authorization to occur before a script is changed or a new script is added to the page, the authorization should be confirmed as soon as possible after a change is made.”

Jscrambler’s Recommendation

WPI is a great solution for managing new and changed third-party scripts. You’ll get a real-time alert as soon as a new or changed script appears, and then you can kick off the authorization process.

Be Present or Execute?

There’s been a very subtle and welcome change to the customized approach objective. In 4.0, it said: “Unauthorized code cannot be present in the payment page as it is rendered in the consumer’s browser.”

And now in 4.0.1, it says: “Unauthorized code cannot be executed in the payment page as it is rendered in the consumer’s browser.”

Jscrambler’s Recommendation

This is a sensible change. It is often impossible to stop malicious JavaScript loading (i.e., being present), but tools like Webpage Integrity can block malicious behaviors in real time. 

Scripts in pages that host PSP’s payment pages in iframes

Most merchants now don’t create the payment form themselves, but they load a Payment Processor/PSP’s form into an iframe. This means they don’t store, process, or transmit cardholder data but because they control the loading of the iframe, they can affect the security of the payment card data.

The first clarification in the Applicability Notes aims to reduce the risk of attacks against the iframe, such as overlay or hijacking attacks:

“This requirement also applies to scripts in the entity’s webpage(s) that includes a TPSP’s/ payment processor’s embedded payment page/form (for example, one or more inline frames or iframes).”

The extension of the requirement to the page hosting the PSP’s iframe was previously included in SAQ A.

Jscrambler’s Recommendation

Moving this applicability from SAQ A into the standard makes it clear and closes a loophole that the requirement did not apply to SAQ-ineligible merchants. In fact, a later 2025 change to SAQ A has removed these two requirements from SAQ A. To be clear, they only explicitly apply now to SAQ-ineligible merchants, BUT they can be used to meet the SAQ A eligibility criteria. If you’re confused, we have a helpful blog post here and a webinar here.

Who needs to comply?

There are two further clarifications in the Applicability Notes that we understand address frequently asked questions sent to the PCI SSC. These are:

This requirement does not apply to an entity for scripts in a TPSP’s/payment processor’s embedded payment page/form (for example, one or more iframes), where the entity includes a TPSP’s/payment processor’s payment page/form on its webpage.

And

Scripts in the TPSP’s/payment processor’s embedded payment page/form are the responsibility of the TPSP/payment processor to manage in accordance with this requirement.

Again, it covers the common architecture in which a merchant’s web page embeds a PSP’s payment page in an iframe. And, although wordy, these two Applicability Notes really just say that:

• The merchant is only responsible for scripts loaded into the page that hosts the iframe (aka the Parent Page) and not for any scripts that are loaded in the iframe.

• The Payment Processor / PSP is responsible for all scripts loaded in the iframe

Jscrambler’s Recommendation

In practice, the clarification of the responsibility for the contents of an iframe is useful, although this was always the intention of the requirement.

However, the clarification would have been better had it made it clear this was only the case when the PSP’s payment page was loaded in a cross-origin iframe. Jscrambler has seen some instances where the PSP’s iframe was created in the same origin as the merchant’s parent page, which means the merchant should be responsible for scripts loaded in the parent page and the payment page in the iframe.

The Merchants’ and PSP’s responsibility

The final change in requirement 6.4.3 can be found in the Good Practice section of the Guidance. 

“Where an entity includes a TPSP’s/payment processor’s embedded payment page/form on its webpage, the entity should expect the TPSP/payment processor to provide evidence that the TPSP/payment processor is meeting this requirement, in accordance with the TPSP’s/payment processor’s PCI DSS assessment and Requirement 12.9.”

This advice complements the new clarification of the responsibilities of merchants and PSPs and makes it clear to the merchant that although they are not responsible for the scripts loaded into a TPSP or a PSP’s iframe, they should check that the PSPs are aware of its requirements.

Jscrambler’s Recommendation

This is good advice in respect of a Payment Processor or PSP, but it doesn’t make any security sense for scripts loaded into a different cross-origin iframe from any non-payment-related Third-Party Service Provider.

PCI DSS Requirement 11.6.1

Just security-affecting changes

Two extremely helpful clarifications have been added to the Defined Approach Requirement. They reflect the initial intent of the requirement and correct what can only be described as sloppy drafting in 4.0.

The original requirement was to detect unauthorized changes to “the HTTP headers and the contents of payment pages as received by the consumer browser.” And in 4.0.1, this has been changed to “the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.”

Clarifying that only changes that can affect the security of cardholder data are the ones that need to be monitored.

Jscrambler’s Recommendation

The change reflects how most entities were interpreting the requirements.

Weekly or every seven days?

In version 4.0, the SSC made a real attempt to harmonize the language used to describe time periods. Requirement 11.6.1 didn’t get the message. It’s now fixed to say “weekly” instead of “at least once every seven days”.

Jscrambler’s Observation

Different words. Same meaning.

Who needs to comply and who is responsible?

The same additions to the Applicability Notes that were added to requirement  6.4.3 have also been added to 11.6.1.

Jscrambler’s Observation

As with 6.4.3, making this requirement apply to the Parent Page of an iframe that contains a payment page will protect against the growing number of attacks targeting iframes. It makes no practical difference, as this provision had already been included in SAQ A.

Improved Guidance

There are some minor clarifications in the Guidance that:

• Explain why checking the HTTP headers is useful in detecting a skimming attack.

• Mirror the Good Practice in 6.4.3 that the Payment Processor should provide evidence that they are meeting this requirement for a payment page in an iframe.

• Detail that the list of examples given is not the only way of potentially meeting the requirement, and also that it’s fine to use a combination of approaches or tools.

Jscrambler’s Recommendation

Highlighting that a combination of approaches can be used to meet the PCI DSS v4 requirements is helpful, although Jscrambler’s Webpage Integrity is sufficient to meet 6.4.3 and 11.6.1 on its own. 

Summary and Conclusion

PCI DSS v4.0.1 is a refinement of the original 4.0 release, introduced to clarify intent, remove ambiguity, and help organizations implement the standard more consistently. While no new requirements were added, they were reworded and expanded to address merchant questions and concerns after the initial release. The table below summarizes the key changes between PCI DSS v4.0 and v4.0.1 at a glance.

Jscrambler Webpage Integrity (WPI) provides a dedicated client-side protection and compliance solution that directly supports PCI DSS v4 requirements 6.4.3 and 11.6.1. WPI gives real-time visibility into all scripts running on your payment pages, alerts you to unauthorized or malicious modifications, analyzes script behaviors, and simplifies the authorization process, helping organizations reduce authorizations by about 90%. 

PCI DSS v4, published in March 2022, introduced critical provisions designed to detect and neutralize e-skimming attacks. Often referred to as formjacking or Magecart, these client-side attacks occur when cybercriminals inject malicious code onto e-commerce payment pages to harvest sensitive cardholder data. 

To allow organizations time to implement these new controls, the requirements were future-dated and became a firm requirement only on April 1, 2025.

With the deadline now passed, compliance with these new requirements is no longer optional; it is mandatory. 

In this guide, we break down the essentials of these now-active requirements and explain how online businesses can ensure they meet the standard.

• What are the specific client-side requirements in PCI DSS v4?

• Who must adhere to these new requirements?

• Where do these protections apply?

• When did the enforcement timeline begin?

• Why is complying with Requirements 6.4.3 and 11.6.1 critical for your business?

• How can e-commerce businesses effectively implement these controls?

What are the new requirements for payment pages under PCI DSS v4?

Requirement 6.4.3

The first requirement (6.4.3) is designed to prevent e-skimming and protect payment and account data. All payment page scripts that are loaded and executed in the consumer’s browser are required to be managed as follows:

• Authorization: A method is implemented to confirm that each script is authorized.

• Integrity: A method is implemented to ensure the integrity of each script.

• Inventory & justification: An inventory of all scripts is maintained, with a written justification for why each is necessary.

Requirement 11.6.1

The second requirement (11.6.1) aims to detect tampering or unauthorized changes to critical components on the payment page and generate an alert when changes are detected. The details of the requirement are as follows:

• Deployment & Scope: A mechanism must be implemented to detect changes and tampering of HTTP headers and payment page content in the consumer browser to ensure security and integrity.

• Detection & Alerts: Personnel must be alerted to unauthorized changes to security-related HTTP headers and scripts on payment pages.

• Frequency: Evaluations occur at least once every seven days OR at defined periodic intervals as established by the organization’s targeted risk analysis (TRA).

Who must comply with requirements 6.4.3 and 11.6.1 in PCI DSS v4?

PCI DSS v4 applies to all entities that store, process, or transmit cardholder data and/or sensitive authentication data. 

Typically, this includes those involved in accepting online payments, such as merchants, Payment Service Providers (PSPs), card issuers, card acquirers, and other service providers.

Where do requirements 6.4.3 and 11.6.1 in PCI DSS v4 apply?

The new requirements (6.4.3 and 11.6.1) apply to online payment pages that process online transactions, such as e-commerce, travel booking, and any services that process sensitive account and payment data, including:

• Cardholder Data: Primary Account Numbers (PANs), cardholder names, expiration dates, and service codes.

• Sensitive Authentication Data: Full track data (magnetic stripe or chip), card verification codes (CVC2/CVV2), and PINs.

These transactions can be conducted on various devices, including desktops, laptops, and mobile devices, and may take place either on a website or within an app.

When do the requirements 6.4.3 and 11.6.1 come into effect?

The new requirements were published in March 2022 as part of PCI DSS v4. As of April 1, 2025, they are now fully in effect, and protections are in place if you accept online payments.

If you have not yet secured your payment scripts, your organization may be non-compliant and vulnerable to both data breaches and assessment failure.

Why comply with requirements 6.4.3 and 11.6.1 in PCI DSS v4?

Simply put: PCI data security is everyone’s business. 

Trust is your most valuable asset. Safeguarding customer data prevents brand damage, reputational harm, and financial losses.

Whether you are a local boutique accepting five payments a month or a massive enterprise accepting five thousand, you are responsible for protecting your customers and their data.

Customers won’t reward you with loyalty if you lose their data. If you handle their information in a way that makes it vulnerable to theft or hacking, they will simply take their business elsewhere.

The fully loaded costs to a business of a data breach are far higher than just a fine. It hits your business in three ways:

• Direct Costs: Lost revenue, incident response fees, fines, and breach notifications.

• Indirect Costs: Loss of brand value, reputation, and consumer trust.

• Opportunity Costs: Lost productivity and cancelled commercial contracts.

How do online businesses comply with requirements 6.4.1 and 11.6.1 in PCI DSS v4?

Now that requirements 6.4.3 and 11.6.1 are in effect, it is critical that you are ready to pass your assessment to avoid  repercussions for non-compliance and any consequences of leaked sensitive data, payment data, and breaches.

To meet the requirements, organizations will need to select technical controls and adopt new management processes for deploying JavaScript. Depending on the size and complexity of the organization, these tasks may not be simple.

Step-by-Step PCI DSS v4 Compliance Guide

To pass your evaluation and avoid penalties, follow this guide to ensure you properly implement the necessary technical controls for managing JavaScript. 

Here are some suggestions for assessing your organization’s current status and moving toward compliance with the new PCI DSS v4 requirements.

1. Audit your current payment page scripts

PCI DSS requirement 6.4.3 only apply to JavaScript on payment pages. Since you can’t manage risks you can’t see, the first task is to assess what JavaScript is currently on your payment page and why it is there.

To do so, we recommend that you:

• Identify Scripts: List the name and URL of every script.

• Categorize: Label as First-party or Third-party.

• Define Purpose: Document exactly what the script does and its business or technical justification.

• Identify Owners: Assign a specific team or person responsible for each script.
  
  

You could do this by looking at the page source in your browser’s developer tools. Or request a free inventory report of all the scripts present on your website from Jscrambler.

2. Review Your Current Change Management Process

Requirement 6.4.3 requires that all JavaScript on the payment page be recorded in an inventory, explicitly approved, and that a record be kept of why the script is necessary.

To help meet this new requirement, you’ll need to understand how JavaScript is added to your website and the business processes currently in place. 

The type of information you’re looking for to help update this process is:

• Access Control: Which teams, people, or processes can/do add JavaScript to the site?

• Approval Workflow: Is there a change management or approval process for this?

• Integrity Checks: Are there existing processes in place to validate the script’s integrity?

• Third-Party Assessment: If the script is loaded from a third party, is a security assessment of that party conducted?

• Deployment Method: Is the deployment of a new script manual or automated? Is it performed by a third party or as a part of your CI/CD process?

• Change Handling: How does the process apply to scripts that change?

• Surface Area Minimization: Is the same JavaScript added to every page on the site, or is it possible to separate the scripts that are included in the payment page from those that are deployed everywhere else on the site?

3. Determine your preferred business process

One of the key decisions you’ll need to make is whether your risk tolerance will allow you to either:

• Approve all changes to JavaScript before they happen.

• Approve changes within a reasonable timeframe after they happen.

This will determine the workflow and the technology that you deploy.

Option A: Pre-change approval

This is best for organizations with static environments.

The pre-change approval workflow: For every script change, your process must:

• Define Governance: Clearly establish who is authorized to request script additions and who has final approval authority.

• Justify the Need: Record specific reasons why the script is necessary for the payment page (focusing on behavior).

• Document Integrity: Log the approval details (who/when) and integrity data (e.g.,hash values or behaviors) for ongoing verification.

• Update & Release: Update your central inventory, approve the release to production, and integrate with your existing deployment pipeline.

Implementation Tip: This can be managed through existing change-control software or, for smaller setups, a strictly maintained spreadsheet.

With a strict pre-deployment approval process you can use strict protective measures such as Content Security Policy (CSP) and Subresource Integrity (SRI). They are based on knowing the hash values of approved scripts because the hash value is computed as part of the pre-deployment process.

However, there are two operational problems with the pre-approval process. 

First, the larger and more complex an organization’s e-commerce platform, the more arduous the process. There’s a real danger that the process won’t be followed if it becomes a roadblock in the development and deployment processes. 

Second, if any script changes (say by a third-party provider), then the script won’t be allowed to load, so the page’s functionality will be affected. In a worst-case scenario, this could break the entire site and prevent customers from checking out.

Option B: Post-change approval

Best for more dynamic e-commerce platforms.

Managing Governance in a Post-Change Approval Model 

In this model, it’s still important to control who in your organization can add new JavaScript to the page and who can approve the script. This is particularly important because you’re effectively defining a time window within which a script is allowed to be active on the payment page before it is approved.

Automation and Compliance 

The workflow relies on automation. The system must detect when a new script is added or an existing one is modified. This detection mechanism serves a dual purpose: it triggers the approval workflow and satisfies the alert requirements of PCI DSS 11.6.1.

Once a change is detected, the workflow should: 

• Log the script’s justification, record the approval details (who and when).

• Document how the script’s integrity was checked (e.g.,hash values or behaviors), and update the script inventory.

If a script is not authorized, you must prevent it from running on the payment page as soon as possible.

A post-approval process is appropriate for more complex environments and ones where an organization has multiple websites or instances of a site. This is especially important where the ability to add JavaScript to a site is distributed throughout an organization or third-parties.

The longer an unapproved changes remains live on a site, the higher the risk. But if we extrapolate from requirement 11.6.1, this time frame should be no longer than seven days. 

However, it allows for scripts to change without the risk of breaking the website, especially important in the case of third-party scripts.

It is also important to note that CSP and SRI are not as appropriate here, as those methods rely on pre-deployment hashing, which contradicts the post-change nature of this workflow.

Jscrambler PCI DSS v4 solution

To effectively manage third-party risk while maintaining real-time visibility and control over every script on a website, using a tool like Jscrambler’s PCI DSS v4 compliance solution is recommended. Jscrambler can support your approval workflows by detecting when a new script is added to a page or any changes are made to an already approved script.

Jscrambler also reduces the risk of unapproved scripts being active on the site during the approval process. It can block malicious behaviors, such as scripts that attempt to access payment card fields on the payment page.

The recent addition of an AI assistant to the Jscrambler client-side protection and compliance platform enhances compliance teams’ ability to manage workflows, improving confidence in client-side security assurance.

Furthermore, Jscrambler offers companies the flexibility to choose different deployment methods through its hybrid architecture. Users can start with a scanner and then implement an agent for comprehensive client-side protection and risk mitigation.

Jscrambler is helping companies comply with PCI DSS v4

Jscrambler helps companies like Scentbird effortlessly comply with PCI DSS v4 requirements 6.4.3 and 11.6 .1 and ensure they foster customer trust. Customers trust Jscrambler to secure their payment pages and support PCI DSS v4 compliance because it is:

• A PCI SSC Principal Participating Organization.

• A member of the PCI SSC Board of Advisors.

• A company with more than a decade of experience protecting JavaScript.

Jscrambler offers a free payment page analysis that helps Merchants assess their compliance readiness with requirements 6.4.3 and 11.6.1 of PCI DSS v4 and QSAs to validate compliance. 

As the payment landscape evolves, compliance with PCI DSS v4 (v4.0.1 is the latest) is now a reality, with the deadline to adopt the future-dated requirements behind us. It is a critical defense against growing web skimming attacks (also known as e-skimming and digital skimming) and data leakage risks.

Two of the standards’ updated requirements, PCI DSS 6.4.3 and 11.6.1, draw a clear line under what’s expected of online merchants and payment service providers: improved change- and tamper-detection capabilities for payment pages.

Under 6.4.3, every script loaded in the consumer’s browser must be catalogued, justified with a business or technical reason, and validated for integrity. At the same time, PCI 11.6.1 mandates a mechanism to detect unauthorized modifications, from header changes to script content alterations, ensuring any suspicious activity triggers alerts. Together, these requirements reinforce PCI DSS compliance as an ongoing, proactive stance against client-side risks such as sensitive data leaks rather than a one-time assessment milestone. 

In this article, let’s break down requirements 6.4.3 and 11.6.1 and present an overview of the most effective tools or methods available on the market for detecting e-skimming activities to meet PCI DSS v4 requirements and keep web skimmers at bay. 

Requirement 6.4.3 Explained

The PCI DSS requirement 6.4.3 calls for businesses to maintain assurance, or in other words, strict oversight, of every script that executes in the customer’s browser on a payment page.

To meet this requirement, organizations must approve each script, verify that it hasn’t been altered, and maintain an up-to-date catalogue that explains the business or technical justification for its presence.

The expectation extends beyond internally developed code to all external and third-party scripts, ensuring that no unvetted or unexpected components are introduced into the payment flow. By strengthening script visibility and accountability, this requirement helps protect against client-side threats such as web skimming and malicious injections that aim to tamper with the checkout experience.

PCI DSS 4 Requirement 6.4.3 Summary 

The goal of requirement 6.4.3 is to prevent data leakage and e-skimming of cardholder data.

• Authorization: A method is implemented to confirm that each script is authorized.

• Integrity: A method is implemented to ensure the integrity of each script.

• Inventory: An inventory of all scripts is maintained, with a written justification as to why each script is necessary.

Requirement 11.6.1 Explained

The PCI DSS requirement 11.6.1 focuses on actively monitoring and detecting unauthorized changes to critical components of payment pages. This requirement mandates that organizations implement mechanisms to identify any alterations to scripts and headers that could indicate tampering or malicious activity. Alerts must be generated when such modifications are detected, allowing rapid investigation and response.

PCI DSS 11.6.1. Summary 

The goal of 11.6.1 is to ensure that client-side attacks, including script injections or web skimming attempts, are identified to prevent the compromise of payment data, reinforcing the security of the overall payment environment.

• Alerting: Any solution must be able to alert personnel when any of the defined behaviors are encountered.

• Headers: A mechanism must be able to detect unauthorized modifications to security-impacting headers.

• Script Content Changes: A mechanism must be able to detect changes to the script contents on the payment page.

• Cadence: A mechanism must be configured to run either weekly or at a cadence defined by a targeted risk analysis.

Relevant Adjustments in PCI DSS version 4.0.1

The PCI Security Standards Council’s PCI DSS 4.0.1 is a limited revision that introduces no new requirements but clarifies and reframes certain existing ones, especially PCI DSS Requirements 6.4.3 and 11.6.1. 

Under 6.4.3, the definition of “necessary” scripts on a payment page shifts from “functionality required to accept a payment” to requiring a documented business or technical justification for every script — making the condition normative, not optional. 

For 11.6.1, the standard now explicitly focuses on detecting only “security-impacting” changes to HTTP headers or script contents, and clarifies that monitoring should occur on a “weekly” cadence rather than “at least once every seven days.”

Organizations That Need to Comply with PCI DSS v4

Is PCI DSS compliance mandatory by law for all merchants that accept online payments? 

The PCI Security Standards Council (PCI SSC) states that the “Council is responsible for managing the security standards, while compliance with the PCI set of standards is enforced by the founding members of the Council, American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc.” 

There is no law, but there can be repercussions for non-compliance and any consequences of leaked sensitive data, payment data, and breaches. Generally, any organization that processes, stores, or transmits payment card data must comply with the standard. 

Below are the main organizations that can be grouped in the following way: 

Merchants

Organizations that accept payment cards. This includes any organization that accepts online payments for goods and services, regardless of size, ranging from small online retailers to large e-commerce websites. 

Payment Service Providers (PSPs)

Third-party organizations that handle payment card data on behalf of merchants or other service providers, including, for example, payment processors and payment gateways.

Financial Institutions

Issuers and acquiring banks, and other financial institutions in the payment card ecosystem have to comply with requirements related to PCI DSS v4.

Teams Responsible for PCI DSS Compliance in Your Organization

When exploring PCI compliance solutions, it’s important to consider the different teams and roles within your organization that will be involved in evaluating, managing, and using them. 

Key stakeholders

PCI Compliance Manager, Internal Security Assessor (ISA), or Information Security Risk & Compliance Manager, usually within the compliance team, must ensure that all PCI DSS-related documentation, script approvals, and assessment preparation meet the PCI standards.

Security teams with a Chief Information Security Officer (CISO), Chief Information Officer (CIO), Head of Information Security in charge, handle ongoing website monitoring and respond to security alerts about suspicious changes. Web Security Managers and Security Architects will typically handle day-to-day tasks. Both compliance and security teams should evaluate a potential solution or tool.

Users

Someone from the software engineering or product development teams should monitor which scripts are present on and added to the website, and maintain the inventory. Developers are usually everyday users of potential PCI DSS solutions or tools.

Since the deadline (1 April 2025) to adopt future-dated requirements is already in the past, the main objective should be to make sure the PCI DSS compliance requirements 6.4.3 and 11.6.1 are adequately met and to simplify the compliance workflows as much as possible, and the right PCI DSS solution should help:

• Get a consolidated, real-time overview of vendors, scripts, and data.

• Reduce manual effort and fatigue with built-in risk analysis.

• Save time and resolve cases faster by automating manual checks.

Dedicated Client-Side Security Tools

There are several client-side security and PCI compliance vendors out there, and legitimate ways to meet the PCI DSS requirements 6.4.3 and 11.6.1.

Each PCI DSS v4 compliance tool has its advantages and disadvantages. What works best for you depends on your organization’s size, your assessment needs, and your overall security posture. 

CSP/SRI 

Content Security Policy (CSP) helps modern browsers restrict which sources can load scripts or other assets, adding protection against data theft and other client-side threats while supporting PCI DSS anti-skimming controls. While Subresource Integrity (SRI) complements this by requiring external resources to match a predefined cryptographic hash, ensuring they haven’t been altered.

When teams review their security posture and PCI compliance solutions, the combination of CSP and SRI is often the first option. This browser-level control helps block injection-based attacks by defining which locations are permitted to serve JavaScript and other resources. In most implementations, the policy is delivered through an HTTP header, allowing the site to enforce strict rules on where scripts can originate. If you’re interested in that approach, make sure to check out the white paper dedicated to it below. 

While CSP and SRI can contribute to PCI DSS v4 compliance, they also come with notable drawbacks that can complicate their use as primary controls. 

Implementing and maintaining CSP policies and SRI hashes can be resource-intensive, especially on dynamic sites with frequently changing or numerous third-party scripts, leading to significant operational overhead and potential functional breakages if hashes become outdated. Moreover, neither CSP nor SRI inherently detects runtime tampering or monitors unauthorized changes to scripts or security-impacting HTTP headers, leaving gaps in satisfying PCI DSS requirement 11.6.1 without additional tooling or processes.

Webpage Monitoring: Scanner (Agentless)

The scanner-based web monitoring solution is a “lightweight” option that many companies prefer, usually when they don’t have many payment pages and brands to manage. It is important to note that a scanner for PCI DSS requirements 6.4.3 and 11.6.1 is different from an ASV scan under PCI DSS requirement 11.2.

This tool offers a quick way to get started with PCI DSS v4, since there is no need for extensive integration and testing before going live. It usually works by scanning your designated payment pages, identifying all third-party services, and reviewing HTTP headers to verify they align with current security requirements. 

Although it can’t block activity like the agent-based approach we will cover next, it delivers the visibility and alerting required for PCI DSS requirements 6.4.3 and 11.6.1.

A key benefit of the scanner tools is that they accommodate situations where inserting code into the website isn’t feasible — for example, when the organization doesn’t directly manage the application or website. 

Webpage Monitoring: Agent

The agent-based tools for PCI DSS compliance offer several advantages that help easily meet PCI DSS requirements 6.4.3 and 11.6.1, as well as being proactive in detecting and optionally blocking suspicious behavior. 

The agent must be injected as a line of code, and monitors website activity 24/7. Because the agent works with real-time browser activity, it continuously observes and evaluates the behaviors flowing through the page.

What makes agent-based solutions stand out is that they enable comprehensive client-side protection and help drastically reduce authorizations. 

For companies that handle millions of transactions annually, it is critical to be proactive and block malicious activity and restrict third-party scripts from accessing customer data on payment pages. It is also helpful to have the option to review complex cases and analyze potential risks associated with third-party vendors and tags.  

Proxy-Based Solutions

Proxy-based solutions sit between the web server and the end user’s browser, giving them visibility into the scripts that are delivered to the client side. They can detect changes in first-party code and, in some cases, even evaluate third-party scripts to validate their integrity before they execute. 

These tools are typically divided into two groups: CDNs and reverse proxies. CDNs use a proxy to inject CSP headers, so it resembles a CSP deployment with automation on top. 

Reverse proxies dynamically tamper with HTML and scripts to prepend URLs with their own and to intercept every third-party hosted script. They can also use static analysis to detect changes.

How Jscrambler Can Help

Jscrambler believes that by making tamper detection and data loss prevention a continuous, proactive practice, organizations can maintain the integrity and trustworthiness of their payment pages while staying compliant with PCI DSS standards. 

Jscrambler gives companies the freedom to choose between agent-based and agentless solutions with a hybrid architecture. It is easy to start with a scanner and later proceed with an agent for comprehensive client-side protection and risk mitigation. With Jscrambler’s behavior-based monitoring, companies can reduce authorizations by about 90%.

The latest addition of an AI assistant to the Jscrambler client-side protection and compliance platform can help compliance teams manage compliance workflows with improved client-side security assurance and confidence.

How Scentbird Ensured Customer Trust with the Jscrambler PCI DSS solution

Jscrambler’s client, Scentbird, has an e-commerce perfume subscription platform built in-house. Developing a website from scratch came with some challenges: the platform had to be user-friendly and highly secure at the same time, and its payment page had to be approved by payment providers. To safely accept payments from thousands of customers, the team needed to be PCI DSS compliant. The Scentbird team considered it a priority to ensure that their customers could trust them with their data.

The Scentbird team initially reviewed cookie consent management tools that claimed PCI DSS support, but these options fell short because they lacked clear answers and practical guidance on PCI-specific requirements. They also considered large platforms like CDNs, which came with high costs and complex, time-consuming integrations. 

As Scentbird co-founder Andrei pointed out, while these platforms frequently introduce broad security features, they tend to address PCI DSS v4 only at a surface level rather than offering focused, in-depth compliance solutions.

With Jscrambler, Scentbird became PCI DSS-compliant in early 2024, well ahead of the 2025 deadline to adopt future-dated requirements and earlier than many e-commerce companies. 

Scentbird emphasized that proactive vendor support was a decisive factor, enabling the team to resolve issues quickly. Scentbird’s CTO and co-founder, Andrei, shared ‘If we have a question and it’s answered quickly, we’re happy. If there’s an upcoming release and we receive a notification several weeks in advance, we can prepare in time. I’d say that having strong support from the team is critically important, especially when it comes to client-side security and compliance.’ With stronger visibility and control over their payment page, the team felt more secure against JavaScript-based threats, giving leadership greater peace of mind and reinforcing the importance of ongoing client-side protection.

Stay up to date on client-side security and PCI DSS v4 compliance by following Jscrambler across our social channels. Connect with us on LinkedIn to get the latest insights, best practices, and product updates.

Today, virtually all websites use JavaScript to seamlessly integrate third-party services. This is primarily to improve their online operations with analytics, user tracking, payments, social media, chatbots, and more. But this adoption comes at a price. Most businesses have no idea what information these tags are collecting. 

Jscrambler research reveals that while 97% of organizations are aware that JavaScript tags collect private and sensitive data, only 13% of organizations are confident that they understand what information these tags collect. And only 26% are aware that these tags leak their private user data to other organizations.

In this article, we will examine how attackers are exploiting JavaScript to capture customer data and corporate intellectual property, using real-life case studies to assess the impact of such breaches in the e-commerce, healthcare, media, streaming, and travel sectors. Plus, offer advice on how businesses can protect themselves from data leakage risks.

E-Commerce: protect customer data and payment pages

The fully loaded costs of a data breach to a business could be potentially massive. These include the direct costs of lost revenue, incident response, fines, and breach notifications. Then, there are the indirect costs, namely the loss of brand value, reputation, and trust. 

For example, Marks & Spencer suffered a devastating cyberattack in March/April 2025, where customers were unable to use contactless payment in-store, shop online, or use click and collect services. E-Commerce accounts for around £3.8 million in daily takings. The attack wiped more than £750 million off its market capitalization and is expected to cost up to £300 million in operating profits this year.

Luxury retailer Louis Vuitton experienced a data breach affecting customers in several countries in June/July 2025. This followed similar attacks on the E-Commerce sites of Adidas, Cartier, Dior, and Victoria’s Secret. The latter was forced to shut down its website for three days in May 2025, although corporate systems were disrupted for longer.  

Prevention Strategies

While the alleged perpetrators behind recent E-Commerce attacks and their modus operandi differ, comprehensive client-side protection exists to prevent data leakage, customer hijacking, web skimming, and Magecart attacks. Safeguard your transactional website and ability to trade and continue trading by:

1. Detecting and Alerting on Suspicious Script Activity 

Analyze the behavior of scripts to identify anomalies such as excessive network requests, or unusual data manipulation, which could indicate a malicious attack.

2. Verifying the Integrity of JavaScript Libraries

Compare JavaScript code with known and trusted scripts to spot tampering with a library or website domain, and to prevent the execution of compromised code.

3. Monitoring and Blocking Malicious Third-Party Scripts

Monitor the execution of scripts, identify suspicious behavior, block scripts exhibiting malicious characteristics, and prevent the exploitation of vulnerabilities.

Healthcare: protect online engagement with patients 

Healthcare applications often handle sensitive data, making them prime targets for cyberattacks. Client-side breaches can result from misconfigurations or malicious script injections, potentially exposing user credentials, Social Security numbers, and Protected Health Information (PHI), and may remain unnoticed for prolonged periods.

This is what happened to two Swedish online pharmacies. They were fined a combined SEK 45 million ($4 million) in early July 2025 for improperly sharing sensitive personal data with Meta. Apoteket AB and Apohem AB installed the Meta Pixel to enhance their Facebook and Instagram marketing efforts. But exposed customer purchasing data, including over-the-counter medicines and sexually transmitted infection testing kits, is classified as sensitive personal data under the GDPR. 

Prevention Strategies

Healthcare businesses can enhance the privacy and security of patient information, while also protecting web apps through:

1. Implementing Polymorphic Obfuscation

Ensure JavaScript code is continuously transformed, making it extremely difficult for attackers to reverse-engineer or tamper with it.

2. Deploying Client-Side Threat Mitigation

Automate control over third-party vendors to prevent web supply chain attacks, data leakage, and customer hijacking.

3. Monitoring in Real Time 

Get instant alerts and benefit from real-time self-defense against tampering, debugging, or poisoning attempts.

4. Getting Compliance Assurance

Allows healthcare organizations to comply with HIPAA regulations by enforcing strict data protection policies and providing detailed audit trails.

Media and Streaming: prevent IP theft and enforce software licensing

 

Reverse engineering, zero-day exploits, code modification, and more: the hacker threat within the entertainment industry is real. Media and streaming businesses must safeguard their intellectual property and digital assets – and with it their revenue and competitive advantage. 

For example, a hacker who stole unreleased music from artists, including Coldplay, Upsahl and Melanie Martinez, received a 24-month suspended prison sentence. The 22-year-old hacker from the UK obtained the music by illegally accessing several cloud storage accounts linked to the artists, and sold the tracks online for around £42,000.

Meanwhile back in 2018, cyber attackers inserted malicious code into a chatbot running on the Ticketmaster website to harvest data from users, including card numbers, expiry dates and security numbers. This resulted in a £1.25 million fine from the UK data protection regulator, a class action lawsuit from victims and ongoing legal repercussions in the US seven years after the breach.

Prevention Strategies

Media and streaming businesses can protect their intellectual property and enforce software licensing with minimal impact on web app performance to:

1. Prevent Piracy

Block any unauthorized access to apps. Harden your video player and protect it against fingerprinting or watermarking technologies.

2. Protect Content

Protect your IP, the player, and the ad revenue running inside it. Keep your unique content safe from competitors and bad actors.

3. Support Team

Save time and resources by delegating the monitoring and protection of JavaScript to a trusted third party.

Travel, Transport, and Logistics: Prevent Web Supply Chain Attacks

Third-party services, such as online booking engines, chatbots, customer review tools, and digital marketing solutions, are transforming the hospitality industry. After all, what business wouldn’t want to streamline operations, enhance customer experience, and provide valuable customer insights?

However, digital transformation also comes with risks, particularly around the use of third-party tags and supply chain attacks. For example, Australia’s largest airline, Qantas, is investigating a cybersecurity breach that exposed the personal data of up to 6 million customers. The airline confirmed in early July 2025 that cybercriminals had accessed a third-party customer servicing system linked to a Qantas call centre.

Prevention Strategies

Travel, transport, and logistics businesses can prevent credit card data breaches, digital fraud, and malicious scripts by:

1. Controlling Script Behavior

Guard against data breaches, web skimming, and more, by blocking unauthorized script behavior.

2. Obtaining Maximum Visibility

Get complete data granularity for real-time threat monitoring and alerts, so you can spot what’s what and what’s not quicker and easier. 

3. Achieving PCI DSS v4 Compliance

Protect against and detect digital skimming attacks on payment pages by certifying against PCI DSS v4, which contains two new requirements effective April 1, 2025.

4. Reducing Data Leakage Risk

One size fits no one in security. Configure your client-side protection to match your organization’s unique data leakage protection needs.

How Jscrambler Helps Prevent Data Leakage Risk

There are no silver bullets in risk management. Rather, it’s best to develop a defense in depth, layered or matrix approach to managing risk. The protection afforded across the various layers or stages becomes greater than the sum of its parts. Consider the following ways to secure your E-Commerce website and web apps:

Get Advanced Protection Through Obfuscation

Obfuscation can deter attackers by making JavaScript code more difficult to analyze and reverse engineer. The best security platforms allow businesses to define their obfuscation policy and needs. Jscrambler allows businesses to integrate obfuscation into their continuous integration and continuous delivery seamlessly (CI/CD) tools. Plus, run obfuscated code without slowing down website performance.

Protect Your Web Apps with Run-Time Defenses and Code Locks

Most obfuscation solutions solely protect code from cyberattacks. Market-leading solutions, such as the one from Jscrambler, go a step further by offering extensive runtime defenses. These defenses empower applications to autonomously detect and react to any tampering, debugging, or poisoning attempts in real-time.

Know When Your Website Is Under Attack

Ongoing monitoring is a second, third, and ongoing chance to check that the risk was correctly assessed in the first place — and is still applicable. For dynamic, international businesses, continuous monitoring is a must.

Jscrambler’s platform allows you to know if your JavaScript code is being debugged, tampered with, or being used outside your desired environment, via alerts and an at-a-glance monitoring dashboard. This enables real-time threat mitigation. 

Benefit From Expert Advice

A security solution is good. But a security solution with expert advice is even better. Jscrambler backs up its products with responsive customer service, high-quality documentation, and industry-specific expertise to address your specific vulnerabilities.

Jscrambler Client-Side Protection Platform

The Jscrambler Client-Side Protection Platform safeguards first-party JavaScript through state-of-the-art obfuscation and exclusive runtime protection.

Its fine-grained JavaScript behavioral analysis also mitigates threats and risks posed by third-party tags. It also complies with the new PCI DSS v4.0 standard for card data security. With Jscrambler, businesses adopt a unified, future-proof client-side security policy, all while achieving compliance with emerging security standards.

Trusted by digital leaders from several industries, including E-Commerce, healthcare, media and streaming, and travel, Jscrambler gives businesses the freedom to innovate securely. Connect with our client-side security experts to try our solutions to prevent digital skimming attacks.