TL;DR: January 2025 SAQ A script attestation eligibility
- Attestation trap: Removing 6.4.3 and 11.6.1 from SAQ A did not make life easier. It replaced them with a self-attestation that "your site is not susceptible to attacks from scripts," and most merchants lack the technical expertise to accurately assess whether they are susceptible to client-side attacks.
- Attack scale: JavaScript is used by 98.9% of all websites, and in January 2025 cside detected over 15,000 newly impacted websites in a single month, with more than 600,000 sites hit in 2024. Scanner-based checks miss stealthy attacks that only trigger 1% of the time or in one region.
- Defending the yes: If you rely on a redirect or an iframe and think you are safe, button hijacks and overlaid fake forms still work. If you want to answer the attestation with certainty, continuous client-side monitoring like cside is the only way to defend the "yes."
Short on time? See cside PCI Shield. It covers everything below in one deployment.
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 to the Self-Assessment Questionnaire A (SAQ A) for PCI DSS (Payment Card Industry Data Security Standard) v4.0.1.
The statement says that, based on feedback from stakeholders, requirements 6.4.3 and 11.6.1 are now removed from SAQ A. Instead, merchants must confirm:
"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 new self-attestation requirement has raised concerns, since many businesses lack the expertise to accurately evaluate their exposure to client-side attacks. These changes create new compliance challenges around client-side security risks, leaving merchants uncertain about their eligibility and responsibilities under SAQ A.
As a client-side security company, we help customers comply with both requirements, and this post explains what the update means in practice.
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 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 the more technical term '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-button:active { background-color: #166534; }
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. To make the attack more stealthy, they can redirect only a certain percentage of visitors, limit it to certain times of day or regions, or avoid the merchant's own IP addresses, letting the attack fly under the radar for a long 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 real payment provider's iframe.
- Hiding the real iframe and replacing it with a fake input.
Other techniques can capture sensitive information just as invisibly.
Related reading: our PCI DSS 6.4.3 and 11.6.1 compliance guide · how to comply with PCI DSS 6.4.3
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 keeping production working properly is a significant challenge, especially with frameworks and platforms such as React, Vue, Magento, Drupal, and WooCommerce. Achieving this level of security manually, without a dedicated solution, is nearly impossible without enormous, fragile effort.
Security risks for merchants designed and managed forms
If your business falls under category 3, where you have built your own payment component, your checkout 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.
NPM scripts can easily inject client-side fetched payloads. Security tools that focus on NPM supply-chain threats struggle to detect these injections effectively, since they lack insight into client-side activity, especially in real time and around the clock.
This viral Medium post from 2018 explains this method in an entertaining way.
3rd party tools
Another common injection method is hijacking a 3rd party script or tool that was added to the website. These can be tools for analytics, adverts, AB testing, widgets, or 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 a 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 CVEs.
The name "Magecart," a legacy term for client-side attacks, originated from client-side injections in Magento used to steal cardholder data. The threat now extends beyond Magento: in January 2025 alone, we detected over 15,000 WordPress websites impacted by new client-side attacks.
JavaScript is used as the client-side programming language on 98.9% of all websites, which makes 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 to monitor the entire client-side environment with an active, real-time tool. This approach goes beyond traditional methods such as point-in-time crawlers, manual script reviews of 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 of day, 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, since it leaves far too many blind spots. In some cases, though, it's 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, which makes it hard to determine clear compliance. Because of that 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 is that some merchants hurry to adopt a 3rd party payment page setup, assuming it improves 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 is that companies simply apply for SAQ A, relying on self-assessment after all, and hoping for the best without addressing the risks.
Increasing risks of client-side attacks
Client-side attacks are increasing in step with the growing complexity of modern browsers.
As a client-side security company, we recommend the most protective approach available, one that safeguards both customers and merchants.
Client-side attacks are on the rise. More than 600,000 websites were impacted in 2024, and in January 2025 alone, we 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.
