DOM (Document Object Model)
PCIComplianceHubLast updated
The live, in-memory representation of a page that the browser builds and that scripts read and rewrite after the HTML arrives. It matters to PCI DSS because payment page attacks operate here rather than on the server: a script can add a field, swap a form action or shadow an iframe in the DOM without the served HTML changing at all. Controls written against server output miss them entirely, which is why Requirement 11.6.1 is specified against the page as the consumer browser receives it.
Applies to. Anyone reasoning about what a payment page is at the moment the customer types. The DOM is the page the browser holds after every script has run, and it is what 11.6.1 asks to be evaluated.
Example. The served HTML has one card form inside a provider iframe. A script then inserts a second, invisible form and rewires the visible button to submit through it. The HTML on the server is unchanged; the DOM is not.
Limits. Server-side change detection, file integrity monitoring on the web root and review of the merchant's repository all see the served page, not the DOM, so they cannot catch this class of change. The Council's definition of payment page scripts includes commands that interact with the DOM, which is why script contents as received by the browser, rather than files on disk, are what 6.4.3 and 11.6.1 govern.
In PCI DSS v4.0.1. 11.6.1 (Payment page header monitoring)