PCI SSC Updates SAQ A for PCI DSS 4.0.1 – What you need to know
On January 30th, 2025, the PCI SSC (Payment Card Industry Security Standards Council) published an update on the Self-Assessment Questionnaire A (SAQ A) for PCI DSS (Payment Card Industry Data Security Standard) v4.0.1.
The statement reads that due to feedback from stakeholders, requirements 6.4.3 and 11.6.1 are now removed from the SAQ A, instead for merchants to qualify for SAQ A “must confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s)”.
This questionnaire applies to merchants who fully outsource payment processing to third-party providers and do not handle or store payment data themselves.
However, the introduction of the new self-attestation requirement has raised concerns, as many businesses lack the expertise to accurately evaluate their exposure to client-side attacks. These changes create new compliance challenges, particularly regarding client-side security risks, leaving merchants uncertain about their eligibility and responsibilities under SAQ A.
As a client-side security company, we assist customers to comply with both requirements, and in this post we aim to clarify the implications of the update.
New responsibilities for SAQ A merchants
The PCI SSC has developed these Self-Assessment Questionnaires (SAQs) to review merchants’ compliance obligations. Merchants are responsible for evaluating whether they meet the requirements outlined in the questionnaire.
SAQ A, designed for the least vulnerable merchants, exempts them from certain PCI DSS requirements given they do not store Card Holder Data (CHD).
With this revision, requirements 6.4.3 and 11.6.1 no longer apply to SAQ A merchants.
Yet, a new requirement of SAQ A is that merchants must self-attest that “their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s)”.
However, many merchants lack the technical expertise to accurately assess whether they are susceptible to client-side attacks.
Given 98.9% of websites currently use client-side JavaScripts, for many merchants this new requirement may make them no longer eligible for SAQ A.
Need for more clarity
The PCI SSC offers a range of Self-Assessment Questionnaires. Still, the SAQ “SAQ Instructions and Guidelines” document has not yet been updated to address these changes.
Given the significant change in scope, we believe an update is necessary to ensure merchants fully understand their compliance obligations.
What is an SAQ A and how to apply
As PCI SSC puts it:
“SAQ A merchants may be either e-commerce or mail/telephone-order merchants (card-not-present), and do not store, process, or transmit any cardholder data in electronic format on their systems or premises.”
Note that the updated eligibility criteria for the SAQ A has been changed to: “merchants with account data functions completely outsourced to PCI DSS validated and compliant third parties, where the merchant retains only paper reports or receipts with account data.”
And now also requires the merchant: “must confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
If a merchant relies on an external provider’s webpage to process payments, merchants have no control over whether a client-side script attack occurs on the 3rd party’s payment page. Monitoring is the responsibility of the payment processor.
Regarding the second group, the statements about iframes are vague and create a false narrative. When using an iframe, it is nearly impossible to completely eliminate the risk of client-side attacks.
To confirm that a merchant's site is not susceptible to client-side attacks, let’s explore when client-side attacks occur or what is considered a client-side attack.
The PCI SSC documentation stopped using the term “skimming” as it is vague and open to interpretation, and instead uses a more technical term of ‘client-side attacks’ or ‘attacks from scripts’.
We define ’client-side attacks’ or ‘attacks from scripts’ as any method a bad actor uses to capture a user’s payment card information directly from their browser.
How client-side attacks occur
There are 3 categories of digital payment pages:
- Redirect payment pages: at checkout a visitor is redirected to a payment provider’s separate domain to enter their payment card information. Once the transaction is complete, they are sent back to the merchant's site.
- An embedded payment form: payment details are collected through an iframe or widget, embedding a 3rd party ‘mini browser’ within the merchant’s website to display the payment provider’s form.
- A merchant designed and managed form: the payment form is designed and managed by the merchants and passes the payment details to the payment processor via API.
Each category has its own security implications, and understanding where and what client-side risks apply is essential for compliance.
Security risks for redirect pages
Redirect pages may seem secure, but merchants have no control over the payment page. If a malicious script is injected, attackers can hijack the redirection process, sending customers to a fraudulent payment page that looks identical to the real one, stealing their payment details in the process. Even when using a trusted third-party provider for the payment, client-side risks remain. Malicious scripts can modify click functions, altering the checkout flow without detection. Using a 3rd party payment provider does not eliminate client-side attack risk, instead it exposes merchants’ sites to a slightly different execution of attacks.
Attack demo: how a payment page can be manipulated
Imagine you are shopping online and click the ‘pay now’ button below.
Pay NowWhen you saw that page, would you think anything was off?
This page took 5 minutes to create. Although you can’t actually enter your payment data on that demo page, with two more minutes of work I could capture any data you input in that payment field, use it to pay the actual merchant. That means you would get your order confirmation and everything would go as expected, while at the same time stealing the credit card information.
Attackers can even dynamically insert the merchant’s logo, making the fake page appear identical to the original site. And to make the attack more stealthy only redirect a certain percentage of end customers, some time of the day or in some parts of the world or even avoiding the IP addresses of the merchant making it easy for the attack to fly under the radar for a large amount of time.
By hijacking the button press that redirects the user to the payment page, the payment processor could not have prevented the attack. The merchant was the only party in this example that could have taken action to prevent the attack.
Security risks for embedded payment forms
If your business falls under category 2, meaning you embed an iframe in your website to display a third-party payment provider’s form, your checkout process remains vulnerable to client-side attacks.
A malicious script can very easily intercept the cardholder data in several ways:
- Rendering another iframe on top of the actual payment providers’ iframe.
- Hiding the real iframe and replacing it with a fake input.
- And various other attack methods to capture sensitive information unnoticed.
Any malicious JavaScript on a merchant’s website would have free-reign over the page and can execute these attacks. The only way to completely eliminate this risk would be to remove all JavaScript from the checkout page or implement super strict CSP headers and SRI directives —which is rarely feasible, as most payment providers (and common critical tools like chatbots, website analytics, error reporting etc…) require dynamic client-side JavaScript to function properly.
Maintaining these controls while at the same time ensuring proper production functionality is a significant challenge, especially when using frameworks and platforms such as React, Vue, Magento, Drupal, WooCommerce etc. Achieving this level of security manually without purchasing a dedicated solution is nearly impossible without enormous effort with breaking impact.
Security risks for merchants designed and managed forms
If your business falls under category 3, where you have built your own payment component, your check-out process is even more vulnerable. These merchant-managed payment forms carry the same hijacking risks as embedded iframes—and more—since other scripts running on the site can keylog payment data.
And how are client-side attacks injected?
Modern web frameworks
Modern single-page web app frameworks, such as React, have become the standard. These frameworks generate “single-page webapps” because they rely on client-side JavaScript to dynamically update the webpage, enabling faster loading and seamless navigation between pages.
However, the entire point of these frameworks is that they don’t reload the page. As a result, scripts added to a specific part of the site can execute on any page, unless a hard refresh is triggered before navigating. This introduces security risks, because malicious scripts can stay active when the user navigates to pages where those scripts were not intended to be.
As a consequence, the original specification’s focus on “scripts on the payment page” becomes ineffective for single-page applications, the most popular approach to web development for many years.
On top of that, modern stack developers rely on open source dependencies from NPM. That makes a ton of sense, as websites perform similar functions and rewriting everything from scratch would be like reinventing the wheel. Using prebuilt libraries speeds up web development significantly.
What many don’t realize is that NPM scripts can easily inject client-side fetched payloads. Security tools that focus on NPM supply chain threats struggle to detect these injections effectively as they lack insight in client-side activity, especially 100% of the time and in real-time.
This excellent viral medium post from 2018 clarifies this method in a rather amusing way.
3rd party tools
Another common injection method is hijacking a 3rd party script/tool that was added to the website. These can be tools for analytics purposes, adverts, AB testing tools, widgets, social media tracking scripts… These scripts often have a dependency tree with many open source tools embedded inside.
The polyfill attack of June 2024 was a major example of this attack method being used in the wild. It's really not that difficult to pull off. Attackers can hijack an S3 bucket, take over an expired domain embedded in websites, claim an abandoned S3 URL or join an open source project and quietly inject some 3rd party dependency… the options are endless.
Injections through the legacy platforms
Even if you use a legacy, often PHP based commerce platform, it has been proven over time that those are highly susceptible to client-side injections through common CVE’s.
The name “Magecart”, a legacy term for client-side attacks, originated from client-side injects in Magento to exfiltrate credit holder data. Yet, this threat extends beyond Magento. In January 2025 alone we have detected over 15000 websites impacted by new WordPress client-side attacks, highlighting the growing risk across platforms.
In this context, it is important to recognize that JavaScript is used as client-side programming language by 98.9% of all the websites, making it a prime target for exploitation.
Therefore, without client-side security, there is no way to confidently rule out an attack or claim immunity to one.
Real-time client-side monitoring for website security
The most effective way to secure your website, and maintain PCI DSS compliance, is by monitoring the entire client-side using an active, real-time monitoring tool. This approach goes beyond traditional methods such as a point in time crawler, manual script review on a payment page or checking the front-end code for known malicious URLs.
Only by continuous monitoring can you confidently state that your “site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s)”.
Client-side scripts are dynamic and can render conditionally. A bad actor could inject a malicious payload that activates in specific conditions, such as triggering only 1% of the time, at a specific time or only for customers in a specific region.
Because of these evasive and stealthy techniques, a scanner-based approach is far from ideal for this vector, as it leaves far too many blind spots… but in some cases it is all you can do so we offer one as a last resort solution.
Do you qualify for SAQ A - Chart
Based on our interpretation, the questionnaire below should help you understand whether you qualify for SAQ A:
Though the vague wording leaves room for interpretation, making it hard to determine clear compliance. Because of the lack of clarity, we suspect that qualifying for SAQ A with certainty is challenging, especially given how close these changes are to the March 31st, 2025 compliance deadline.
In practice, most merchants would struggle to confidently answer “yes” to the question:
“The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
One possible outcome could be that some merchants hurry to adopt a 3rd party payment page setup, assuming it enhances security and qualifies them for SAQ A. Still, this does not eliminate the risk of credit card theft if their website’s scripts are compromised, as explained with the button hijacking method.
Another likely outcome could be that companies simply apply for the SAQ A, relying on self-assessment after all, and hoping for the best without addressing the risks.
Increasing risks of client-side attacks
Considering the current attack landscape and the increasing complexity of modern browsers, businesses reach a pivotal point.
As a cybersecurity company, we will always advocate for the safest approach, one that actively protects customers and businesses alike.
Client-side attacks are on the rise. More than 600.000 websites were impacted in 2024 and in January 2025 alone, we have detected over 15,000 newly impacted websites.
Your Responsibility: Continuous Monitoring
The best way to ensure PCI DSS compliance is to monitor your entire client-side environment in real-time. It’s your responsibility to stay ahead of these threats and protect your customers.
For any clarifications or questions, contact us today.