COMPLIANCE AND REGULATORY UPDATES

PCI DSS Payment-Page Scripts and E-Skimming: Evidence for Requirements 6.4.3 and 11.6.1

Contact OC Security AuditMeet Ali Hassani, CISO

E-commerce payment path showing first-party and third-party browser scripts passing through authorization, integrity, inventory, and tamper-detection controls
Intelligence CenterCompliance and Regulatory UpdatesLast fact-checked July 2026Analysis by Ali Hassani, CISO

PCI DSS payment page scripts can run in the customer’s browser even when the payment function is outsourced. Analytics, tag managers, chat, consent tools, fraud services, advertising, accessibility tools, A/B testing, content delivery, and payment integrations may all influence the page that surrounds or embeds a payment function. If an attacker changes an authorized script, introduces a new one, or alters a security-impacting page element, payment data may be captured before it reaches the intended processor.

PCI DSS v4.x Requirements 6.4.3 and 11.6.1 address this browser-side risk. The goal is not to produce a spreadsheet once a year. It is to know which payment-page scripts are allowed and why, use a method to support their integrity, detect unauthorized changes, investigate alerts, and retain evidence that the process operates.

Executive summary

The PCI Security Standards Council (PCI SSC) released its information supplement on payment-page security and e-skimming in March 2025. PCI SSC states that:

  • Requirement 6.4.3 focuses on authorizing payment-page scripts, assuring their integrity, and maintaining an inventory with written justification;
  • Requirement 11.6.1 focuses on change and tamper detection for payment pages and security-impacting HTTP headers;
  • the controls apply to relevant e-commerce implementations, including pages that can affect embedded payment forms;
  • the supplement provides guidance and does not add, replace, or supersede PCI DSS requirements;
  • validation method, scope, and reporting should be confirmed with the organization managing the compliance program, such as an acquirer or payment brand.

The two requirements became effective on March 31, 2025. PCI SSC also changed SAQ A reporting: the specific requirements were removed from SAQ A, while an eligibility criterion requires applicable merchants to confirm their sites are not susceptible to script attacks that could affect e-commerce systems. That reporting change does not make browser-side payment risk disappear.

Start with the payment-page architecture

Document how a consumer reaches payment and where each page element originates. Common patterns include:

  1. the merchant hosts the payment fields and scripts;
  2. the merchant page embeds a payment processor’s form or iframe;
  3. the merchant page redirects the browser to a processor-hosted page;
  4. a single-page application loads payment components dynamically;
  5. a tag manager or content system injects scripts into pages that can influence checkout.

Scope and responsibility depend on the actual implementation. PCI SSC FAQ 1331 gives a server-side redirect as an example where an assessor could determine 6.4.3 and 11.6.1 not applicable because the redirect mechanism is not susceptible to script-based attacks; the assessor still needs to test and document non-applicability. A client-side redirect or merchant page containing an embedded payment form can present a different risk.

The architecture record should identify the merchant, hosting provider, e-commerce platform, payment processor, content delivery network, tag manager, script providers, security service, developers, and monitoring provider. State who authorizes scripts, who can change the page, who receives alerts, and who preserves evidence.

Realistic e-commerce operations environment correlating script inventory, content changes, security headers, alerts, approval records, and investigation evidence
Script integrity is an operating process: authorized components are matched to an inventory, unexpected change is isolated, and response evidence is preserved.

Requirement 6.4.3: manage every relevant script as an asset

PCI DSS describes three connected outcomes for scripts loaded and executed in the consumer’s browser: confirm authorization, assure integrity, and maintain an inventory with written justification. An operational inventory should include more than a URL.

Recommended fields include:

Field Purpose
Script or component identifier Distinguishes the item from similar files or dynamic loaders
Source and delivery domain Shows first-, third-, or fourth-party origin
Page and execution condition Identifies where and when it loads
Business purpose Explains why the script is necessary
Data and DOM access Shows what the script can read or change
Owner and approving role Establishes accountability
Authorization date and change record Proves review and approval
Integrity method Records how unauthorized modification is prevented or detected
Dependency or downstream load Identifies scripts introduced by another script or tag
Removal or expiry condition Prevents abandoned code from remaining indefinitely

Discover scripts as the browser renders the page, not only by reading a server template. Dynamically loaded scripts, tag-manager content, customer-specific paths, consent-driven code, and third-party components may not appear in a static source review.

Authorization should be a decision

An authorized script should have an owner, business purpose, security review appropriate to risk, approved source, and change path. “It was already on the site” is not written justification. Remove code that no longer supports a necessary function.

Integrity requires a method suited to delivery

Possible techniques include controlled hosting, file validation, deployment controls, content security policy, subresource integrity where technically appropriate, change detection, or provider-supported mechanisms. No single technique fits every dynamic or third-party script. Document why the chosen combination assures integrity for the implementation and how failures are handled.

Subresource integrity, for example, depends on a known expected resource and can be difficult when a provider changes a script frequently. A content security policy can restrict sources but may not prove that an allowed source’s content is trustworthy. The evidence should describe the limitation and the layered control, not merely list a security header.

Requirement 11.6.1: detect unauthorized change and respond

The monitoring process should cover relevant payment-page content and security-impacting HTTP headers as the page is received by the consumer. The system should establish an approved baseline, detect changes, generate an alert, and support investigation. PCI DSS includes a frequency expectation for the mechanism, with an alternative frequency based on the standard’s targeted risk-analysis process where applicable; confirm the exact assessment requirement for the organization’s validation method.

Monitor items that can affect the security of payment data, such as:

  • new, removed, or changed scripts;
  • script source, hash, size, behavior, or loading sequence;
  • inline code and event handlers;
  • iframe source and attributes;
  • security headers and content security policy;
  • forms, destinations, and checkout routing;
  • tag-manager changes;
  • unauthorized page elements or network destinations.

Detection without response is incomplete. Define alert owner, severity, validation steps, business-hours and after-hours escalation, evidence preservation, containment authority, processor coordination, and return-to-service criteria.

Build an evidence chain, not a screenshot collection

An assessor or internal reviewer should be able to follow one script from discovery through approval, integrity control, monitoring, alert handling, and periodic review.

Useful evidence includes:

  • current payment flow and responsibility diagram;
  • complete rendered-page script inventory;
  • written business justification and approval;
  • configuration or code showing the integrity method;
  • baseline and monitored page list;
  • sample scheduled results and alert output;
  • ticket showing a real or test alert investigated and closed;
  • change-management record tying an approved deployment to the inventory and baseline update;
  • access lists for the e-commerce platform, tag manager, code repository, deployment system, and monitoring console;
  • periodic review record removing an unnecessary script;
  • targeted risk analysis when used for a permitted frequency decision;
  • documentation supporting SAQ eligibility or assessor-determined non-applicability.

Evidence should come from the period being assessed and the production implementation, not only a demonstration tenant. Export machine-readable inventories and events where possible. Preserve timestamps, page locations, decision owners, and version information.

Understand the SAQ A distinction

PCI SSC announced in January 2025 that Requirements 6.4.3 and 11.6.1 were removed from SAQ A and added an eligibility criterion for a merchant to confirm its site is not susceptible to script attacks that could affect its e-commerce systems. PCI SSC explained that merchants may use techniques from the two requirements or obtain appropriate confirmation from the compliant third-party provider supplying the embedded payment form, depending on the implementation.

This is a reporting and eligibility distinction, not a universal exemption for every e-commerce page. Confirm that the organization meets every current SAQ A eligibility criterion and that the implementation matches the processor’s instructions. Ask the acquirer, payment brand, qualified security assessor, or other compliance-program manager which validation method applies.

PCI SSC’s 3-D Secure script FAQ also describes a specific trust relationship for scripts used for 3DS functionality. It does not excuse unrelated scripts that run outside that purpose.

Common implementation failures

Inventory from only one scan

A scanner may miss geography, consent, authentication, customer segment, device, or transaction-dependent code. Validate representative paths and change conditions.

Every script marked necessary

Written justification should connect each script to a real business or security function. Remove dormant marketing tags, old experiments, duplicate libraries, and abandoned vendor code.

Monitoring the server but not the browser

An e-skimming control should account for what the consumer’s browser receives, including third-party content and security headers. Server file integrity alone may not see changes introduced elsewhere in the delivery chain.

Alerts with no accountable response

Test the path from detection to triage, containment, evidence preservation, processor contact, and restoration. Record false-positive decisions and tune without hiding meaningful change.

Trusting a provider statement without mapping responsibility

Identify which scripts and page elements the provider controls and which remain under the merchant, platform, tag manager, or another third party. Obtain evidence for the precise boundary.

Treating compliance as the only objective

The browser-side controls protect payment information and customer trust. They should operate as part of secure development, change management, vendor management, incident response, access control, and vulnerability management—not as an assessment-week exercise.

A 30-day readiness plan

Days 1–7: map and discover

Document payment flows, pages, iframes, redirects, providers, scripts, security headers, tag managers, deployment paths, and owners. Confirm the validation method and current SAQ or assessment scope.

Days 8–15: authorize and reduce

Assign owners, write justification, remove unnecessary scripts, restrict change access, confirm change approval, and select integrity controls suited to each delivery model.

Days 16–23: monitor and integrate

Deploy or validate page and header monitoring, define baselines, connect alerts to ticketing or incident response, protect monitoring administration, and retain testable evidence.

Days 24–30: test and document

Perform an authorized change, confirm detection, investigate the alert, update the baseline through change management, and assemble the evidence chain. Review responsibilities with the e-commerce platform and payment provider.

OC Security Audit’s PCI DSS cloud, e-commerce, POS, and payment-application guidance and common PCI DSS gaps can help place these browser controls inside the wider payment-security program. The PCI DSS scope and readiness check is a starting point, not a formal assessment or validation decision.

Questions leaders should ask

  • Can we list every script that runs on each relevant payment path and explain why it is necessary?
  • How is authorization recorded and integrity supported?
  • Are we monitoring the rendered consumer experience and security-impacting headers?
  • Who receives and investigates an alert outside business hours?
  • What evidence shows that the process operated during the assessment period?
  • Does our current SAQ or assessment method match the actual architecture?
  • Have our acquirer, payment brand, assessor, and payment provider confirmed responsibilities?

Sources

Turn payment-page requirements into operating evidence

Contact OC Security Audit to discuss PCI DSS scope, e-commerce security, evidence readiness, or an independent control review. Learn more about Ali Hassani, CISO and his experience across cybersecurity, infrastructure, compliance auditing, network security, and executive guidance.

Use the PCI DSS customized-approach and compensating-control guide when the control design differs from the defined approach, connect technical monitoring with payment-verification controls for business email compromise, and apply software-vendor due diligence to third-party scripts and services.

Update and correction history

  • July 2026: Initial analysis prepared from current PCI SSC standards, supplement, FAQs, and SAQ guidance available through July 2026.