As the deadline for PCI DSS 4.0 compliance approaches in March 2025, businesses must prepare for new security requirements related to websites using JavaScript and iFrames for payment pages. The latest version of PCI DSS introduces two important requirements: managing all payment page scripts and ensuring real-time detection and alerts for unauthorised script changes. These updates address the rising threat of client-side attacks like Magecart and e-commerce skimming.
What is the purpose of the new PCI DSS requirements?
The primary objective is to address the rising threat of client-side attacks (identified in the 2024 Verizon Data Breach Investigations Report) such as cross-site scripting (XSS), form-jacking, and e-commerce skimming attacks, particularly Magecart attacks. These attacks involve injecting malicious scripts into payment pages to siphon off sensitive user data. These scripts can operate in real-time, stealing payment card (and PII) information as the consumer enters it.
Modern webpages often rely on assembling content (primarily JavaScript) from multiple Internet locations on a consumer’s device. While this approach has made websites faster, more customisable, and more dynamic, it’s also made the client side a favourite target for hackers, who can leverage the piecemeal nature of modern websites by exploiting and modifying scripts to gain access to consumer cardholder data.
This was an issue before PCI DSS v4.0 was introduced, the new requirements were added as future-dated requirements for websites that use iFrames or JavaScript for payment pages. However, we are now fast approaching the deadline of 31st March 2025 when the controls will change to be mandatory.
What are the new PCI DSS requirements?
The two new requirements are;
PCI DSS requirement 6.4.3 requires merchants and service providers to know and manage all payment page scripts loaded and executed in the consumer’s browser.
PCI DSS requirement 11.6.1 focuses on the proactive detection and response to potential security threats. Merchants and service providers must be alerted when a change has been made (intentionally or unintentionally). By comparing the current version of the HTTP header and the active content of payment pages as received by the consumer browser with prior or known versions, it is possible to detect unauthorised changes that may indicate a skimming attack, or an attempt to disable a control designed to protect against, or to detect, skimming attacks.
For merchants completing SAQ A, using an iFrame will mean the two additional requirements are in place. This is likely to cause additional work as websites are commonly outsourced to third parties (often multiple). Understanding who will perform these checks should be your first act to make sure you have time to meet the requirements before the deadline.
How will PCI DSS compliance checks work for the new requirements?
A PCI DSS QSA approach for examining compliance within section 6.4.3 will be similar to this:
- 4.3a: Policies and procedures will be reviewed to verify that processes are defined to manage consumer-facing browser payment page scripts.
- 4.3b: Inventory records and configuration settings will be checked to verify that all consumer-facing browser payment page scripts are authorised, have been integrity checked, and have a business case or justification as to why they are being used.
- 6.1a: System settings, payment pages, and monitoring logs will be examined to verify there is a change and tamper detection mechanism deployed.
- 6.1b: Configuration settings will be checked to ensure the mechanism has been set up compliantly, and that it evaluates the received HTTP header and payment page.
- 6.1.c: Merchants and service providers are required to either perform the checks weekly or complete a documented risk assessment to ascertain a safe frequency of checks. An audit will include an analysis of this risk assessment and verification that the requirement is performed at the necessary frequency.
How to comply with the new PCI DSS Requirements
Several approaches are available to comply with PCI DSS requirements 6.4.3 and 11.6.1, each with benefits and challenges. Three key options to consider are:
- Payment Page Redirect
- In-House Solution
- Third-Party Solution
Payment Page Redirect
While this method renders requirements 6.4.3 and 11.6.1 not applicable, redirecting your customers to an entirely hosted payment page (not using iFrames or direct post), all scripts load from the third-party payment processor’s site, so the new requirements are their responsibility.
Although you must still manage other PCI DSS requirements, this option significantly minimises risk since the PCI DSS-compliant provider handles all payment-related risks.
Good:
- Simplifies PCI DSS compliance.
- Reduces cost.
- Lowers the risk of script-related vulnerabilities.
Bad:
- You lose control over the customer experience on the payment page.
- Shopping cart abandonment may increase due to unfamiliar payment gateways and sudden URL changes.
- Development is required to implement this payment redirect (initially).
In-House Solution
If maintaining control of the checkout process is important, organisations can implement technology and procedures to meet these requirements. The PCI DSS standard outlines a few strategies:
For 6.4.3
- Sub-Resource Integrity (SRI): Enables website administrators to ensure that only the intended version of a script is loaded on their site.
- Content Security Policy (CSP): Allows website administrators to restrict the content sources allowed on their site. A whitelist of authorised sources determines which scripts get loaded and executed on the payment pages.
- Tag/Script Management Systems: This can be utilised to manage scripts.
- Browser extensions like Wappalyzer, ScriptSafe, NoScript, or uBlock Origincan be used to list scripts running on a consumer’s payment page.
For 11.6.1
- Monitor and report any CSP violations or changes.
- Use external systems (Synthetic Monitoring) to compare current content with a known safe state.
- Use tamper-detection scripts to alert/block malicious behaviour on the payment page.
- Utilise a third-party reverse proxy or content delivery network.
Good:
- Full control over implementation and better website ‘look and feel’.
- CSP can manage which scripts are executed and where data can be loaded from or sent to, while SRI ensures script integrity.
- Can be cost-effective as there’s no need to buy a fully external solution.
- Synthetic scanners can be unintrusive and used for script inventory and management.
Bad:
- Developing and maintaining CSP and SRI is complex and time-consuming.
- In-house expertise is required for ongoing monitoring and updates to CSP.
- Frequent script changes from third-party providers may lead to payment page malfunctions if CSP configurations aren’t updated efficiently.
- Separate script inventory required
- Synthetic monitoring checks operate at timed intervals, so some changes may not be noticed immediately.
Solutions (of many):
- Akamai Page Integrity Manager (CDN)
- Cloudflare (CDN)
- Dynatrace (Synthetic Monitoring)
- Grafana (Synthetic Monitoring)
- New Relic (Synthetic Monitoring)
The above list of mechanisms is not exhaustive, and the use of any one mechanism is not necessarily a full detection and reporting mechanism.
We advise reviewing any potential solutions with a PCI QSA before implementation to ensure they fully meet the requirements.
Third-Party Solution
Purchasing a dedicated third-party solution is ideal for organisations that don’t want to implement a full redirect and lack the internal resources to create an in-house solution.
Good:
- Designed specifically to mitigate risks addressed by the new PCI DSS requirements.
- CSP and SRI operate in the consumer’s browser, requiring minimal changes to your environment.
- Simplify policy configuration and monitoring of breaches and alerts.
- Most solutions can block unwanted scripts (this is over and above what the requirement requires but is good for security).
Bad:
- Cost can vary depending on transaction volume and the number of websites – costs can be significant.
- It’s essential to ensure the solution fits your requirements and to balance its cost against the expenses of developing an in-house option.
Solutions (of many):
Whether you’re considering a third-party solution, an in-house approach, or a payment page redirect, OmniCyber Security can help you navigate these changes and secure your payment environment.
Contact our expert team today to learn more about how we can assist with your PCI DSS compliance strategy and ensure you’re ready ahead of the March 2025 deadline.
