How to Prove Your Website is Secure Against Script-Based Attacks
The March 31st deadline for PCI DSS 6.4.3 and 11.6.1 enforcement is fast approaching. However, a recent update from the PCI Security Standards Council (PCI SSC) offers certain merchants a potential exemption from these requirements, provided they meet specific conditions.
This raises key questions:
- Do SAQ A merchants still need to focus on 6.4.3 and 11.6.1?
- Can SAQ D or SAQ A-EP merchants transition to SAQ A for a streamlined compliance approach?
- What’s the most effective way to demonstrate your website is secure against script-based attacks?
This blog clarifies these points and provides both a short- and long-term roadmap to PCI DSS compliance.
PCI Wants to Stop Script-Based Attacks. Period.
At its core, PCI DSS requirements 6.4.3 and 11.6.1 were introduced to protect payment pages from script-based attacks. Whether you’re a Level 1 merchant processing millions of transactions or a small e-commerce site, the expectation is the same: you must prove your website is not susceptible to malicious script injections.
Your approach to compliance depends on:
- Your Merchant Level,
- Your SAQ (Self-Assessment Questionnaire) category,
- Whether you store, process, or transmit cardholder data (CHD).
Until January 2025, every e-commerce merchant was expected to implement measures for 6.4.3 and 11.6.1, regardless of their SAQ category. However, a recent PCI SSC update introduced a conditional exemption for merchants completing SAQ A, allowing them to mark these requirements as “Not Applicable”, but only if they meet two conditions:
“All elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor.”
“The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
This update does not mean SAQ A merchants can ignore security and shift responsibility to a TPSP. They still need to demonstrate that their website cannot be compromised by script-based attacks, even if they don’t directly serve payment pages.
The question is how, and the measures and controls necessary for requirement 11.6.1 are good starting points for demonstrating to the PCI SSC that your website is “not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
For SAQ D or SAQ A-EP merchants, while moving to SAQ A can be a long-term strategy for compliance simplification, it’s not a quick fix for meeting the March 31st deadline.
How to Prove Your Website is Secure Against Script Attacks
For merchants who remain under SAQ D or SAQ A-EP, 6.4.3 and 11.6.1 still apply. However, implementing the right technical measures can help you achieve compliance faster and pave the way for a future transition to SAQ A.
Requirements 6.4.3 and 11.6.1
Requirement 6.4.3
Requirement 6.4.3 requires merchants to inventory, review, and authorize all scripts running on their payment pages. Each script must have a documented business justification and integrity checks to prevent unauthorized modifications.
The starting point for many organizations often involves using Content Security Policies (CSP). While CSP allows organizations to allow-list script sources and block unauthorized scripts, they have some major limitations, namely:
- They struggle with dynamic scripts: CSPs can’t validate scripts that update dynamically (e.g., CDN-hosted libraries like jQuery).
- They require constant maintenance: CSPs in report-only mode generate extensive logs, which require manual triage of thousands of entries, taking valuable time away from your team.
- They provide no integrity checks: CSPs lack native mechanisms to verify script integrity beyond URL allow-listing.
Likewise, organizations might also look to using Subresource Integrity (SRI) tags. However, like CSPs, SRI tags also have their limitations, such as:
- They only work for static scripts: SRI tags fail for scripts that update frequently, such as analytics and A/B-testing tools, which marketing teams often use.
While CSPs and SRIs provide a starting point, you’ll need additional technical solutions to fully and efficiently meet the PCI SSC’s requirements. In fact, the right solutions can make reaching requirements 6.4.3 and 11.6.1 much easier and quicker, which is now more critical than ever as the time to the March 31st enforcement deadline is within striking distance.
Requirement 11.6.1
Requirement 11.6.1 mandates weekly detection of unauthorized modifications to payment pages, including scripts and security-impacting HTTP headers, or more frequent monitoring based on a risk analysis.
CSPs and SRI tags are ineffective in fully addressing requirement 11.6.1, leaving several gaps that bad actors can exploit in real-world scenarios, such as:
- Unchecked multi-day windows for attackers to find and exploit vulnerabilities outside of your scheduled monitoring days.
- Lack of header monitoring from CSPs and SRI tags. These lack the native capabilities to validate security-impacting HTTP headers, leaving another potential gap for attackers to exploit.
- Excessive manual processes will require you to invest significant time from your team to verify alerts, increasing response times and increasing the risk of mistakes.
Best Practices for Meeting Requirements 6.4.3 and 11.6.1
Going beyond the PCI SSC’s baseline requirements is important.
First, it makes your system much more resilient to script-based attacks. Ultimately, you must ensure you’re well-defended from such attack as a breach can lead to costly problems, like being placed on the PCI’s Designated Entities Supplemental Validation (DESV) list.
Second, applying the best tools also makes meeting requirements 6.4.3 and 11.6.1 much more efficient. For example, you can eliminate manual tasks like triaging hundreds or thousands of log entries from CSPs, or use automation to monitor your payment pages 24/7.
When looking for tools to meet requirements 6.4.3 and 11.6.1, focus on the following:
1. Real-Time Script Cataloging
Use a solution that identifies every script (be it inline, first-party, third-party, or dynamically loaded) as your payment page loads. This will eliminate blind spots from legacy tools that use static inventories. It also helps reduce risk by detecting unauthorized scripts injected by compromised third-party vendors (e.g., outdated jQuery plugins) before they execute.
Leverage a tool that maintains a real-time registry of script versions, origins, and vendor details. This will help streamline the script auditing process under requirement 6.4.3. It will also remove the need to manually triage logs from CSP report-only mode.
2. Automated Authorization and Integrity Checks
Consider relying on the services of a PCI DSS-validated TPSP to perform integrity checks on your payment pages. This would allow you to confirm that your site is not susceptible to attacks from scripts that could affect the tour e-commerce system(s).
3. Browser Independent Tamper Detection and Blocking
Avoid script-based tools that need to run on the browser. Script-based tools provide limited browser support, leaving your e-commerce systems’ security and compliance at the mercy of vulnerable users. Moreover, because such solutions are scripts, their ability to operate is predicated on being the first script to run. A malicious script could potentially run before them, rendering the solution useless.
Instead, use a proxy-based solution that covers all browser types and runs independently of your scripts. This solution will block malicious and/or unauthorized script changes. It will also monitor your security-impacting HTTP headers for unauthorized changes and block those as well.
4. Real-Time Monitoring and Threat-Blocking
Leverage a solution that takes a proactive approach to threat management rather than a reactive one. Many solutions aim to address requirement 11.6.1 by detecting threats and providing alerts. However, these solutions fail in meeting requirement 6.4.3, which states: “Unauthorized code cannot be executed in the payment page as it is rendered in the consumer’s browser.”
Instead, use a solution that provides real-time monitoring and threat-blocking. Doing so will ensure that you’re both meeting requirement 11.6.1 as well as protect you from threats and, consequently, the risk of a data breach.
Overall, DataStealth’s eSkimming Protection solution provides all of the above with scalability, automation, and real-time response/blocking capabilities. By adopting DataStealth’s eSkimming Protection, you not only achieve compliance but also gain credible defensibility against script-based attacks.
DataStealth’s solution provides the groundwork to demonstrate to the PCI SSC that your payment pages – and wider website – are not susceptible to script-based attacks. You can demonstrate capabilities like real-time 24/7 monitoring of scripts and security-impacting HTTP headers, real-time tamper detection, alerting and blocking, and universal browser coverage as proof.
SAQ A Eligibility With Exemption to Requirements 6.4.3 and 11.6.1
Once you leverage a solution like DataStealth’s eSkimming Protection to demonstrate that your payment pages are not susceptible to script-based attacks and meet requirements 6.4.3 and 11.6.1, you can start working towards audit scope reduction. The following measures can potentially reduce the number of systems in scope and, in turn, move you toward SAQ A eligibility.
1. Move Your Payment Card Data to a PCI DSS-Compliant TPSP
To qualify for SAQ A, you’ll need to move your cardholder data (CHD) to a PCI DSS-compliant TPSP. The goal is to basically move the CHD out of your environment, leading to a reduction in the number of your systems under PCI DSS scope.
DataStealth’s PCI Audit Scope Reduction solution provides this service using data tokenization, i.e., replacing the CHD with substitute values. DataStealth tokenizes the CHD before it reaches your system and de-tokenizes it after the CHD leaves. Moreover, DataStealth hosts your CHD in its PCI DSS Level 1-compliant environment, thus fully securing it from end to end.
2. What Happens to Requirements 6.4.3 and 11.6.1 When you’re a SAQ A?
In February 2025, the PCI SSC released FAQ 1588 clarifying that requirements 6.4.3 and 11.6.1 would not apply to a “merchant with a webpage that redirects customers from the merchant’s webpage to a TPSP/payment processor.” Besides redirects (e.g., HTTP 30x redirects, meta redirect tag, or JavaScript redirect), providing customers a link to the TPSP’s website to pay also exempts the merchant from requirements 6.4.3 and 11.6.1).
In other words, if you have completely outsourced all your payment functions to a TPSP, then you’re exempt from requirements 6.4.3 and 11.6.1.
However, SAQ A merchants with a webpage that “include a TPSP/payment processor’s embedded payment page/form” (including one or more inline frame(s) or iframes) must implement additional security controls to confirm that their pages are “not susceptible” to script-based attacks.
The PCI SSC states that this process can be achieved in one of two ways:
“Using techniques such as, but not limited to, those detailed in PCI DSS Requirements 6.4.3 and 11.6.1 to protect the merchant’s webpage from scripts targeting account data. These techniques may be deployed by the merchant or a third party.
Or
“Obtaining confirmation from the merchant’s PCI DSS compliant TPSP/payment processor providing the embedded payment page/form(s) that, when implemented according to the TPSP’s/payment processor’s instructions, the TPSP’s/payment processor’s solution includes techniques that protect the merchant’s payment page from script attacks.”
In effect, the PCI SSC wants merchants with payment elements on their webpages to implement strong security controls, and requirements 6.4.3 and 11.6.1 provide a strong starting point.
These rules show that the PCI SSC wants merchants to prioritize securing themselves against script-based attacks. Merchants leveraging DataStealth’s eSkimming Protection would have an advantage in meeting these requirements immediately as they transition to SAQ A.
Take control of your compliance strategy today. Simplify your PCI DSS compliance by partnering with a PCI-compliant service provider. Strategic planning and real-time monitoring reduce risk, strengthen security, and save valuable resources. Contact our team today for a consultation and build a streamlined, secure compliance strategy.
