Pedro Fortuna, Chief Technology Officer & Co-Founder, Jscrambler
For anyone unfamiliar with SAQ A, it is the Self-Assessment Questionnaire A, which can be used to validate merchant compliance with Payment Card Industry Data Security Standard (PCI DSS) for merchants that have fully outsourced all payment card data processing to PCI DSS-validated payment service providers (PSPs). For SAQ A-qualifying businesses, it provides a faster, simpler path to PCI DSS compliance while also allowing them to demonstrate their commitment to security. Taken together, it may seem like the ideal route to achieving compliance, until it isn’t.
A recent example of this involves Stripe and, more specifically, Stripe merchants, who were targeted by a digital skimmer called MirrorMask. The threat actors injected malicious code that proxied Stripe’s iframe, allowing them to intercept payment form data and spoof security headers before it reached Stripe’s secure processing.
Despite these actions, the pages appeared normal, and all customer transactions were processed as expected. Little did merchants know that cardholder data was being silently skimmed as customers checked out. MirrorMask was first reported by Turaco Labs, and later our own Jscrambler team identified that 49 merchants were affected as of April 2, 2025.
At this point, I’d like to point out that Stripe is just one example. This attack method could just as well have targeted a payment iframe from any other service provider. Whatever the case, the lesson would be the same — SAQ A alone doesn’t ensure protection, even when the PSP is fully compliant with PCI DSS.
The Blind Spot in SAQ A
When SAQ A debuted in 2008, it simplified compliance for merchants whose cardholder data functions are completely outsourced to validated third parties, with the merchant retaining only paper reports or receipts containing cardholder data. But much has changed since then. Modern websites now rely on dozens of third-party scripts to power everything from analytics and chatbots to tag managers and marketing pixels. In each instance, these are running client-side.
Today, as we learned from impacted Stripe Merchants, attackers are compromising third-party scripts and dependencies loaded on merchant payment pages and, by injecting malicious code into these components, can intercept and exfiltrate sensitive data directly from payment fields before it reaches the payment service provider (PSP).
Here’s a deeper look at how this attack worked in the MirrorMask incident.
A Deep Dive into The MirrorMask Attack
In e-commerce, SAQ A assumes that the merchant has outsourced the risk to the payment gateway and that the payment gateway protects the merchant against skimming attacks.
The “Mirror Mask” attack destroys this assumption.
The attacker compromised the merchant’s website so that the payment script loads from the attacker’s server rather than Stripe’s. When the merchant’s customers entered their payment card data, it was first sent to the attacker’s server. The attacker took a copy before forwarding the payment to Stripe, which couldn’t detect that a threat actor had intercepted the transaction.
The Growing Gap Between Compliance and Security
PCI DSS acknowledges the skimming risk, but SAQ A falls short of fully addressing it. Some requirements call for businesses to monitor the integrity of webpages and script behavior — specifically, requirements 6.4.3 and 11.6.1 — but they were removed from SAQ A before becoming mandatory. Had they been in place, this attack could have been detected and prevented.
Taking Ownership of Client-Side Security
At this point, the question is, where does this leave merchants? MirrorMask and similar attacks provide the answer. Namely, responsibility for payment security doesn’t end with the payment service provider. Merchants must take active ownership by ensuring that their integrations are tamper-resistant and properly validated. That starts with asking the right questions:
- Can the embedded payment iframe detect unauthorized code injection on the parent page?
- How is its integrity verified in real time?
- Who is accountable if client-side code on the merchant page is compromised?
While the answers will vary by merchant, every organization should maintain strong technical controls to protect against client-side threats such as Magecart and e-skimming. This includes site-wide script monitoring, integrity validation, and tamper-detection mechanisms.
Continuous validation and monitoring are key. By actively verifying the integrity of payment pages and collaborating with compliance experts, merchants can strengthen their defenses, ensure ongoing compliance with PCI DSS v4.0, and maintain eligibility under SAQ A.
The Road Ahead
SAQ A helped merchants simplify PCI DSS compliance. But things have changed. Merely being compliant, or taking a low-resistance path to compliance, is insufficient as a line of defense against modern-day attacks. Security must extend beyond paperwork to include real-time verification on the merchant side that examines what the business has decided to allow to run in the browser.
For merchants, that means pairing compliance checklists with continuous visibility and control. For PSPs, it means designing payment iframes/hosted fields that detect tampering from the merchant’s side. And for the ecosystem, it’s a reminder that trust without verification remains an open invitation to attackers.
About the Author
Pedro Fortuna serves as Co-Founder & Chief Technology Officer, responsible for technology innovation, product strategy, and R&D at Jscrambler. Pedro brings over 20 years of experience in software engineering and security, leading innovative products from concept to market.
Pedro sits on the PCI SSC Board of Directors and is a qualified Internal Security Assessor (ISA). He is also a regular speaker at international security conferences, an inventor, a co-author of several AppSec patents, and involved in the local application security community, co-leading the OWASP Porto chapter.
Recent PaymentsNEXT news:
Decoding the UK Data Bill: What It Signals for Trust, Innovation, and Competitive Advantage