PCI Evidence From the Script Inventory

PCI DSS 6.4.3 asks for three things about the scripts on a payment page: each one is authorized, its integrity is assured, and an inventory is kept with a written justification for why each one is necessary. 11.6.1 asks that unauthorized changes to what a payment page loads are detected. On the Professional plan and above, HeaderHawk keeps that inventory from the scripts your visitors’ browsers report and the scripts its daily scan of each payment page finds in the page’s HTML, records each decision about them, and alerts when an unreviewed, changed or rejected script runs on a payment page. See Script Integrity Monitoring for how it works.

This page is about the export: the file you hand an assessor. The Compliance page composes it with the scans and alert rules into a status for each requirement; see PCI DSS Readiness.

Getting it

On the Scripts page, open the Payment pages view and choose Export CSV. The file covers the selected site, and reaches back as far as your plan keeps reports.

What each row says

One row per script and payment page it ran on, or whose daily scan found it. A script seen on two payment pages is two rows.

Column	What it is
Payment page, Page pattern	The payment page, as you marked it (Payment Pages)
Script URL	The script, without its query string
Status	unreviewed, authorized or rejected
Integrity mode	For an authorization: pinned_hashes or any_content
Pinned hashes	The versions an authorization with pinned hashes accepts
Hashes seen	Every version browsers reported or the scan found; (not hashed) for a browser report of a script loaded without CORS
Justification	The current decision’s written justification
Decided by, Decided by email	Who made the current decision, as they were named at the time
Decided at	When
First seen, Last seen	The script’s first and last report on your pages in the period the file covers
Seen by	browsers, scan or browsers and scan: what has seen any version of it
Last scanned	When a daily scan in the period last found it; empty when none did

The lines starting # above the header say which site the file is for, when it was made, the period it covers, and what it cannot show.

Every earlier decision is kept on the script’s history in the dashboard: who authorized or rejected it, when, why, and what they pinned. A decision is never edited or deleted, only followed by another, so the history is the record of how a script’s status came to be. The export carries the current decision; the history carries every one.

A cell a spreadsheet would treat as a formula starts with ', so a script URL or a justification cannot run as one when the file is opened.

What it cannot show

An inventory of what ran, not proof that nothing else did

Every row comes from a browser that reported a script, or from the daily scan of a payment page finding it in the page’s HTML. The export says so in its first lines, and an assessor should hear it from you too.

• Only Chrome and Edge report script hashes. Visitors on Firefox and Safari contribute nothing. The daily scan fetches the scripts a payment page’s HTML names regardless.
• A cached script reports nothing. A returning visitor whose browser already has the script sends no report for it. The daily scan fetches it anyway, if the page’s HTML names it.
• A browser cannot hash a script loaded cross-origin without CORS, so its report has no hash. The daily scan is not subject to CORS and records a hash that can be pinned, for a script the HTML names. Adding crossorigin="anonymous" and a CORS header on the server that hosts it makes browsers report one too.
• A script another script adds is seen only by browsers. The scan reads the HTML and runs no JavaScript, so the tags a tag manager loads, for instance, are in the export only when a browser reported them.
• Inline scripts are not in it. Browsers report the scripts they fetch; inline code is not a fetch. Report-only violation reporting covers inline scripts separately.
• First seen and Last seen reach back only as far as your plan keeps reports. The decisions and their history do not expire: they stay until the site is deleted, including after a downgrade.
• Authorization is recorded, not enforced. A rejected script runs until your site stops loading it or your enforced Content-Security-Policy blocks it. HeaderHawk alerts when it keeps running.

Together these mean the export is evidence that the scripts in it ran and were reviewed, not that no other script ever ran. Pair it with an enforced script-src allowlist, which is what actually stops an unlisted script, and whose violations HeaderHawk reports.