What are the signs that a web application may have been tampered with to divert customer traffic or steal payment details?

Common warning signs include unexplained changes to page scripts, unusual outbound requests, checkout behaviour that differs by browser or region, and customer complaints about failed payments or suspicious redirections. Security teams should also watch for third-party code drift, unexpected domain references, and access logs that show activity inconsistent with normal purchase flows.

Why Tampering Shows Up as Checkout Drift, Redirects, and Quiet Script Changes

When a web application has been tampered with to divert traffic or capture payment details, the earliest indicators are often behavioural rather than obvious breakage. A page may still load, but one browser sees different checkout logic, a region-specific path is redirected, or a small script edit silently changes where card data is posted. In practice, the warning signs surface first in customer friction, unusual outbound requests, and third-party code that no longer matches the approved baseline.

That matters because payment skimming and traffic redirection are designed to blend into normal commerce flows. A successful attacker wants the site to keep working just enough to avoid immediate attention while they siphon data or route users away from the legitimate endpoint. The most useful signal is usually a mismatch between what the application should do and what it is actually doing at runtime, especially in the checkout path. NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful control reference for monitoring integrity, logging, and access paths that support that kind of detection. In practice, many teams discover tampering only after customer complaints or payment anomalies have already exposed the issue.

How It Works in Practice

To spot tampering, teams should compare the live application against a trusted baseline at three layers: code, network behaviour, and transaction outcome. Code-level drift often appears as altered scripts, injected third-party references, or checkout forms that submit to an unexpected host. Network-level drift shows up as unusual outbound requests, especially from pages that normally should not call external domains during payment entry. Transaction-level drift includes failures that cluster by browser, geography, or device class, which can indicate conditional skimming or selective redirection.

The most reliable investigations look for relationships between these signals rather than any single symptom:

page source or bundled assets that no longer match the approved release artifact
script tags, iframes, or event handlers introduced outside the normal release process
checkout requests or beacon traffic sent to domains not used by the business
payment failures that are uneven across browsers, regions, or payment methods
access logs showing admin, CMS, or deployment activity that does not fit the purchase cycle

For payment theft, the critical question is whether sensitive fields are being observed, copied, or forwarded before they reach the intended processor. For traffic diversion, the question is whether routing logic, DNS references, or injected client-side code changes the user journey after page load. The State of Secrets in AppSec is useful here because secret leakage and code integrity failures often travel together, and leaked deployment credentials or API keys can make this kind of tampering possible.

These controls tend to break down when teams lack an immutable baseline for checkout assets, or when content changes are expected often enough that malicious edits hide inside normal release noise.

Common Variations and Edge Cases

Tighter checkout integrity controls often increase operational overhead, so teams have to balance release speed against the need to detect subtle tampering. Not every redirect is malicious, and not every failed payment means skimming, which is why context matters.

Some legitimate changes can resemble compromise: A/B testing, payment processor failover, regional routing, bot mitigation, consent tooling, and tag-manager updates can all alter page behaviour. The difference is governance. Approved changes should be traceable to a release, a ticket, or a controlled configuration update, while malicious changes usually lack that lineage. Browser-specific differences are especially important, because skimming code is sometimes hidden behind conditions that only trigger for certain user agents, geographies, or high-value checkout paths.

Another edge case is server-side compromise that leaves the visible page intact but alters form submission, headers, or backend-to-backend forwarding. In those situations, front-end inspection alone is insufficient; teams need to correlate application logs, payment processor telemetry, and outbound request patterns. Where third-party scripts are involved, the presence of an external domain is not itself suspicious, but unexplained domain drift or new script behaviour outside the release process should be treated as a material warning sign. When the site is under active fraud pressure, treat checkout anomalies as a containment problem first and a forensic problem second.

Risk and Threat Considerations

The main risk is silent compromise of the customer-facing path, especially the checkout flow where attackers can intercept payment details or steer users to fraudulent destinations without breaking the site outright. That creates both confidentiality risk and revenue risk, and it can also damage trust long before the compromise is technically confirmed.

Failure mechanism: Attackers typically exploit weak release controls, compromised admin or deployment access, vulnerable third-party scripts, or server-side injection points to alter client-side code, payment routing, or external references. Once inserted, the malicious logic can be selective, conditional, and hard to detect from normal user testing.

Impact: Customer payment data can be exposed, redirected transactions can fail or be stolen, and downstream fraud response can become expensive because the compromise may persist across multiple pages or deployments until the altered asset is identified and removed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	DE.CM — Security Continuous Monitoring	Detects unexpected script, network, and checkout drift in a live application.
	PR.AC — Identity Management, Authentication and Access Control	Access control failures often enable tampering through compromised admin or deployment paths.
Recommendation — Monitor page integrity and outbound behaviour for deviations from the approved baseline. Restrict publishing and deployment access to approved, auditable identities.
CIS Controls v8	8 — Audit Log Management	Logs are needed to correlate abnormal checkout activity with unauthorized changes.
	16 — Application Software Security	Application integrity and secure release practices directly address script and flow tampering.
Recommendation — Centralise and review logs for changes, redirects, and payment-flow anomalies. Validate application changes and protect release pipelines from unauthorised modification.
MITRE ATT&CK	T1195 — Supply Chain Compromise	Injected third-party code or compromised dependencies can alter checkout behaviour.
	T1059 — Command and Scripting Interpreter	Tampering often relies on injected client-side or server-side script logic.
Recommendation — Hunt for dependency or script compromise when checkout behaviour changes unexpectedly. Inspect suspicious scripts and payloads that change payment routing or data capture.

Practitioner Guidance

What to prioritise: Treat the checkout path, payment form assets, and third-party script inventory as the highest-value integrity surface. If any of those change outside the approved release path, investigate before assuming the issue is a benign frontend bug.

What to verify: Confirm that the live page matches the deployed artifact, that outbound destinations are expected, and that browser or region-specific differences are intentional. The most useful proof is a clean chain from approved change to observed behaviour, not a general assurance that the application was recently deployed.

Decision rule: If suspicious behaviour appears only in the payment journey, escalate as potential tampering even when the rest of the site looks normal. Payment skimming often aims to preserve availability while quietly changing one data path.

Practitioner takeaway: The fastest way to miss web tampering is to look only for outages; the better test is whether the customer journey, the asset baseline, and the outbound destinations still agree.