CSP and SRI help, but they are fragile as standalone controls. CSP can be bypassed or lose protection if an allowed domain is later compromised. SRI can stop altered scripts, but it also locks teams into fixed versions and can be bypassed through tag manipulation. Neither control alone gives continuous, behavior-based detection in the browser.
Why CSP and SRI stop being enough against Magecart
CSP and SRI are integrity controls, but Magecart attacks usually win by changing what the browser is allowed to trust, not only by serving an obviously altered file. If an injected script comes from an approved origin, if a page already relies on many third-party assets, or if attackers can manipulate tags and loading paths, the controls become a filter instead of a full defence.
That is why the failure mode is often not “the policy was absent”, but “the policy was too static for a page that changes often”. CSP is only as strong as the trust set you maintain, and SRI only protects the exact resource hash you pinned. For web skimming, those assumptions are easy to undermine when the page builder, tag manager, or dependency chain is the real entry point.
The browser can still execute malicious logic when the attack happens inside allowed delivery patterns. That is the central weakness: the control can validate origin or file integrity while still missing abuse of legitimate loading behaviour, runtime manipulation, or scripts introduced through an already-allowed path.
What the attack path usually looks like in practice
Magecart operators target the client side because it sits close to payment data and is hard to observe from traditional server-side telemetry. The common pattern is to alter a script, inject a new script through a trusted dependency, or manipulate the DOM so that card data is copied out before the page submits it.
CSP helps most when it narrows where scripts can come from, and SRI helps most when the same script file is expected to stay stable. But checkout pages often need CDNs, analytics, tag managers, and rapid front-end releases, which means the trust boundary is broad and changes frequently. That operational reality makes static controls brittle unless they are paired with monitoring and tight change governance.
This is also where supply-chain and delivery-path trust matter. If an approved script host, publishing pipeline, or tag management path is compromised, CSP may still permit it and SRI may not cover every dynamically assembled resource. The browser is then executing trusted code that has been subverted upstream, which is exactly why content integrity controls alone do not close the window.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 16 — Application Software Security | Magecart abuses web app delivery paths and client-side code integrity. |
| CIS 8 — Audit Log Management | Client-side skimming needs monitoring and evidence of unexpected browser activity. | |
| CIS 10 — Malware Defenses | Web skimming behaves like browser-side malicious code execution on payment pages. | |
| Recommendation — Harden checkout scripts and dependencies with secure build and release controls. Collect and review logs that can reveal script changes and checkout abuse. Deploy layered defenses that can detect malicious script behavior on the client side. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Magecart targets payment data in transit through the browser. |
| DE.CM — Continuous Monitoring | Static controls miss browser-side tampering unless runtime behavior is observed. | |
| PR.AC — Identity Management, Authentication and Access Control | Allowed script sources and trusted paths are an access-control problem for the browser. | |
| Recommendation — Protect sensitive checkout data with layered controls beyond page integrity checks. Monitor client-side and delivery-path behavior for unexpected script activity. Minimize and review trusted script sources and execution paths. | ||
| MITRE ATT&CK | T1056.001 — Keylogging | Magecart-style skimming often captures payment data as it is typed or submitted. |
| T1059.007 — JavaScript | Attackers commonly use JavaScript on the client to manipulate checkout pages. | |
| Recommendation — Model browser skimming as credential and data capture behavior in detection logic. Hunt for malicious JavaScript execution and unusual client-side script chains. | ||
Practitioner Guidance
What to prioritise: Treat CSP and SRI as baseline hardening, then add controls that detect abuse in the browser, not just file replacement on the server. For payment pages, review every third-party script, tag manager dependency, and inline script exception as a potential trust expansion.
What to verify: Confirm that the page still works when script allowances are reduced to the minimum needed for checkout, and test whether dynamic tag insertion, compromised approved domains, or DOM-based injection can still move sensitive data. If the answer is yes, the control set is incomplete.
Practitioner takeaway: The right question is not whether CSP and SRI are deployed, but whether the checkout page has any remaining trust path that can be abused without breaking those controls.
Related resources from NHI Mgmt Group
- What is the difference between Content Security Policy and Subresource Integrity in JavaScript security?
- Why does Content Security Policy leave gaps against Magecart-style web skimmers?
- What breaks when Content Security Policy is too permissive in Angular apps?
- What breaks when application security controls are too weak against credential stuffing?
