How to Make Payment Forms PCI Compliant and Secure Against Formjacking Under PCI DSS 4.0.1

Formjacking involves malicious code injected into payment forms that captures credit card data during transactions. The form functions normally, the payment completes, and nothing unusual appears in server logs. This happens in the browser, outside the reach of traditional server-side security controls. PCI DSS 4.0 requirements 6.4.3 and 11.6.1 extend compliance to the client side to address this.

What you’ll learn in this article:

• How formjacking works and why major organizations suffered breaches despite strong security programs
• Requirements 6.4.3 and 11.6.1 explained with a practical 4-step implementation framework for script inventory, integrity validation, and continuous monitoring
• Manual vs. automated compliance costs including evidence requirements, response workflows, and what QSAs actually accept during audits

Having worked with dozens of payment processors and e-commerce platforms, we’ve learned that compliance does not guarantee security. Many businesses have been passing their PCI audits while their forms remain wide open to attacks. These new PCI requirements are designed to minimize that disconnect. 

What is Formjacking and how it connects to PCI DSS 4.0

Formjacking refers to a type of cyber attack that involves injecting malicious JavaScript code into online payment forms to extort credit card data. The script runs during the transaction, unbeknownst to the user, raising no suspicions. 

Here’s how it typically unfolds:

1. Hackers compromise a third-party script on the payment page by exploiting an entry point, usually a third party tool. Once the vendor script is compromised, the injected code runs through websites using that service. 
2. The code runs in the background while users fill the form, capturing personal data. It blends with legitimate code to escape the detection radar.
3. The exfiltrated data is transferred to attacker-controlled servers. This happens when the customer visits the infected page. 
4. The transaction completes successfully, leaving no trace of foul play in server logs. The user completes their payment normally, clueless about the data theft.

Formjacking incidents that made headlines

Formjacking incidents occur every day. They’re often not widely reported, but here are some of the most notable ones: :

Earlier versions of PCI protected servers and databases, but lacked requirements for browsers and other client side tools. This is what led to such egregious formjacking incidents. . Requirements 6.4.3 and 11.6.1 address this by mandating visibility, integrity validation, and tamper detection in real time. 

Requirements 6.4.3 & 11.6.1 Explained

Drafted under the broader requirement 6 involving application and system security, requirements 6.4.3 and 11.6.1 transform the way attackers target payment card data. 

Requirement 6.4.3 

6.4.3 deals with script management and introduces an additional layer of security for websites handling payment data. Organisations should: 

• Implement a control to authorise all scripts
• Validate the integrity of all scripts
• Maintain an inventory to justify the existence of all scripts 

From a security perspective, PCI 6.4.3 adds visibility to ensure that shadow scripts don’t escape the radar. Mandating inventory maintenance and authorisation reduces the attack surface by making script injection harder. 

Requirement 11.6.1

Legislated for tamper detection, 11.6.1 mandates compulsory change and tamper detection systems for payment pages. Organisations must:

• Trigger alerts if unauthorised changes in payment page contents and HTTP headers are detected
• Monitor every seven days or set a frequency based on risk analysis
• Set up investigation procedures and response protocols for detected changes

With a focus on real-time monitoring, 11.6.1 aims to close vulnerabilities opened by periodic reviews. Given that formjacking codes may appear between the review windows, real-time detection and automated monitoring help to close unauthorized modifications before they inflict damage.

How 6.4.3 and 11.6.1 work together for holistic security 

In summary, 6.4.3 is all about prevention and control, while 11.6.1 is designed for better detection and response. Together, they form a closed loop. Attackers can’t inject or modify code without triggering an alert, and authorized scripts can’t execute if their integrity fails validation.

Note that 11.6.1 explicitly calls for automation. Manual processes, even with screenshots, quarterly reviews, and other obligations fall short. PCI DSS auditors outright reject manual attestations. 

Building a sustainable PCI DSS 4.0 compliance strategy

If you are adopting PCI DSS for the first time, complex clauses and legal speak may seem daunting at first. We built this clean, logical flow to walk you through each implementation phase to simplify the process. 

Step 1: Know where your scripts hide 

On average, about 50 to 100 scripts run in a website’s background. These include static scripts embedded on payment forms, tag managers, containers, dynamically loaded scripts triggered by user interactions, and fourth-party dependencies. 

Keeping track of the script inventory manually is not feasible or reliable. For smaller teams, browser DevTools or “view source” works, but can be time intensive and pull up only one snapshot at a time. As you scale, it cannot reliably detect scripts loaded dynamically or conditionally. 

A client side monitoring solution efficiently captures script activity across sessions and automatically identifies nested dependencies. You gain continuous visibility as load increases.

This is where Feroot’s automated discovery creates immediate value. Rather than manually checking DevTools or running periodic scans, Feroot maintains a live inventory of every script across all payment pages, including dynamically loaded dependencies that traditional tools miss.

Step 2: Document why each script is needed

This is how auditors see it: if something is not documented, it didn’t happen. Once you have the inventory, maintain a clear record of each script’s justification, department/individual accountable for it, vendor details, and if it accesses payment fields. 

Ideally, the workflow should look something like this: Security identifies → Business justifies → Privacy reviews → Approve or remove. At this phase, you may discover risk codes like inactive marketing tags, A/B testing tools or fourth-party dependencies running in shadow IT. 

In short, use a default-deny policy: if a script doesn’t have a clear purpose, it doesn’t belong on a payment page.

Step 3: Monitor script integrity

Malicious actors can alter script behavior to add hidden fields or siphon data to their server. Use either of these methods to ensure integrity:

1. Subresource Integrity: SRI adds cryptographic hashes to script tags loaded from CDNs. The browser verifies if the script matches the expected hash before execution. However, it is limited to static scripts and breaks when legitimate vendor updates occur. It’s a foundational control but insufficient alone.
2. Behavioral Monitoring: Scans scripts at runtime to detect suspicious activities like accessing form fields, sharing data to unapproved domains, or modifying DOM.

Feroot recommends: Using both together provides stronger assurance: SRI for integrity, behavioral monitoring for intent.

Step 4: Build response and correction workflows

Preventive controls are the first line of defense, but not the ultimate failsafe. When alerts fire, your IT team should: 

=> Verify the alert, disable the compromised script, and notify payment operations immediately (within hours) 

=> Next, identify the entry point, determine the exposure score and affected transactions, and document the forensic evidence (hours to days)

=> After the incident, determine the root cause, notify relevant vendors, and patch vulnerabilities  

Feroot accelerates this workflow by providing instant alerts with forensic context: which script changed, what data it accessed, and which external domains received information. This cuts investigation time from hours to minutes because the evidence is already captured.

Manual vs. Automated Compliance

There’s more than one approach to compliance – manual, semi automated, and automated. 

As we stated earlier, manual approach works for smaller teams but breaks as you scale. Building an inventory from scratch, conducting reviews, and annual reauthorization can eat up about 160 to 200 hours a year and cost up to $35,000. Most importantly, vulnerability windows remain open unless you adopt continuous monitoring (required by 11.6.1). 

With automated processes, you spend 30 to 60 hours on average to set up and manage internally while spending not more than $45,000. From a compliance perspective, continuous monitoring helps you meet 11.6.1, remediate breaches in real time. It pays for itself in peace of mind through audit ready evidence while significantly reducing QSA validation time. 

Feroot’s approach sits in the automated category. Initial setup takes 2-3 weeks, ongoing maintenance averages 30 minutes per week (mostly reviewing alerts), and the platform generates audit-ready evidence continuously. Most teams see ROI within the first audit cycle from reduced QSA validation time alone.

Audit Evidence Requirements

To satisfy PCI DSS 4.0, evidence must be concrete and continuous.

Requirement 6.4.3 evidence:

• Complete script inventory with justifications.
• Authorization records and data-access documentation.
• Integrity validation methodology (SRI, behavioral monitoring).

Requirement 11.6.1 evidence:

• Description of automated monitoring solution.
• Alert samples showing detection capability.
• Proof of 24/7 coverage.
• Documented response procedures.

QSAs have made one expectation clear: proof of continuous, automated monitoring is mandatory. Manual reviews or screenshots no longer suffice.

Frequently Asked Questions

See how Feroot keeps you compliant  

Formjacking prevention and PCI DSS 4.0 compliance are no longer separate efforts – they’re two sides of the same protection strategy.

Requirements 6.4.3 and 11.6.1 mandate the same controls that actively prevent breaches: knowing what scripts run, validating their purpose and integrity, and detecting tampering instantly. When implemented correctly, they transform compliance from a paperwork exercise into a live control framework.

Feroot’s automated client-side monitoring reduces hundreds of hours of manual work into ongoing, invisible protection. It’s the difference between hoping to pass an audit and knowing your payment pages are continuously defended.

The result is quiet confidence forms that stay secure, customers that stay protected, and compliance that proves itself every minute of the day. Talk to our compliance experts today.