Key points
• 11.6.1 focuses on detecting unauthorized page and header changes.
• A useful baseline should represent the real customer-facing checkout flow.
• Alerts need ownership, triage, and evidence retention to be audit-ready.
What should be monitored
Teams should monitor the real payment page, important DOM changes, script changes, form behavior, and security-relevant HTTP headers.
The baseline should be reviewed when legitimate releases change the checkout experience.
How to avoid noisy monitoring
The process should separate expected release changes from unknown changes. Owners need a way to approve, explain, or investigate each deviation.
Why file integrity monitoring is not the whole answer
File integrity monitoring can detect server-side file changes, but it may miss CDN modification, dynamic injections, third-party script behavior, or the final headers and DOM delivered to the customer.
For 11.6.1, the payment page has to be treated as a customer-facing artifact: what loaded, which headers arrived, and how that differs from the approved baseline.
Triage and evidence
Detection only matters if the team can classify the event. The process should define who receives alerts, who investigates changes, how legitimate releases are recorded, and where the final evidence is stored.
Compare page states without blindly hashing HTML
Full HTML often contains session identifiers, localized content, personalization, and values that change on every load. Hashing the entire document creates noise, while broad exclusions can hide material changes. Define stable signals for each state instead: script sources and content, loaders, request destinations, security-relevant DOM elements, and security-impacting HTTP headers.
Normalization rules must be versioned and testable. For every exclusion, retain the reason, owner, and a negative test proving that the rule does not hide a new script, destination change, or weakened header.
A minimum change-event contract
An event should link the observation to a specific payment state and baseline version. A useful record includes the change type, new value, time, release context, owner, decision, and evidence references. A useful timeline captures the path from first observation to closure rather than only a visual diff.
- 10:02 — a new source is first observed on the payment page.
- 10:06 — an owner is assigned; no matching release is found.
- 10:20 — the source is contained or escalated through the procedure.
- 10:42 — decision, action, and closure evidence are retained.
- Monitoring workflow: Payment page change detection
- Method boundaries: JSIR monitoring methodology
Illustrative event for triage
{
"event_id": "evt-2026-0716-17",
"payment_state": "checkout.payment",
"baseline_id": "base-2026-0715-r3",
"observed_at": "2026-07-16T10:02:11Z",
"change": {
"type": "script_source_added",
"value": "https://new.example/loader.js"
},
"release_id": null,
"owner": "security-operations",
"decision": "investigate",
"evidence_refs": ["snapshot-884", "headers-884"]
}