Magento checkout security: Magecart, price tampering and protecting the payment process
By Kike Gandia · Co-Founder & CEO, OSCP
The checkout process is the most critical component of a Magento store from both a security and a business standpoint. A failure here can mean stolen card data, order fraud or loss of customer trust. Attackers know this, and it's where they focus their most sophisticated efforts.
Magecart risk: card skimming at checkout
Magecart attacks inject malicious JavaScript that captures card data entered by the user in the payment form, before it reaches the gateway. The most common entry vector is a compromised or outdated third-party extension, a module with an XSS vulnerability that allows scripts to be injected, or an external CDN dependency with no restrictive CSP policy.
Detection requires active analysis of every script with access to the checkout DOM, a review of the server's file-integrity history and an analysis of the Content-Security-Policy headers.
Price tampering and business logic
Magento calculates prices, discounts and totals on the server, but the process involves multiple AJAX calls between the browser and the API. Business-logic testing examines: whether the final amount can be modified by tampering with request parameters, whether discount coupons have limits correctly validated on the server, whether the prices of products with configurable options can be altered, and whether catalogue price rules apply the correct restrictions per customer group.
Security of payment gateway integrations
Payment gateways in Magento are implemented as PHP extensions with access to order data and, in some cases, to card data before tokenisation. The payment integration audit covers: signature validation in callbacks and webhooks, secure handling of payment tokens, the absence of sensitive-data logging in accessible log files, and correct error-flow handling to avoid duplicate orders or unconfirmed payments.
What PCI DSS requires regarding payment page scripts
Version 4.0 of the standard stopped treating control over checkout scripts as a recommended good practice and turned it into an enforceable requirement. In practice that translates into two obligations that directly affect how a Magento store is built.
The first is keeping an inventory of every script loaded on the payment page, with a business justification for each one and explicit authorisation: if nobody knows why a script is there, it should not be there. The second is having a mechanism that detects unauthorised changes to the HTTP headers and to the content of the payment page, and alerts when they happen. A Magecart skim is precisely that: a script appearing without anyone having authorised it. If a store processes payments with card data passing through its own checkout, this is the part of the standard that generates the most technical work.
Where each checkout control lives and how to verify it
Almost all of these controls are assumed and almost none are checked. This is the mapping between the control, where it is configured and the test that proves it works.
| Control | Where it is configured | How to verify it |
|---|---|---|
| Inventory of payment page scripts | Checkout template and tag manager | Compare the scripts loaded in production against the authorised list |
| CSP with allowed origins | Web server or CDN headers | Try loading an unauthorised script and confirm it is blocked |
| Integrity of external resources | Checkout script tags | Verify that every external resource carries its integrity hash |
| Signature validation on payment webhooks | Gateway module | Replay a tampered callback and confirm it is rejected |
| Server-side amount calculation | Cart and catalogue rules | Tamper with the total in the request and confirm it is recalculated |
| Logging without sensitive data | Payment module log configuration | Search the log files for card numbers and tokens |
| Payment page change detection | Integrity monitoring | Introduce a controlled change and confirm the alert fires |
FAQ
Does a strict CSP policy fully protect against Magecart?
It is the most effective mitigation, but it is not enough on its own. A CSP can be misconfigured (too permissive), can have exceptions for business-critical scripts, or an attacker can exploit a first-party script to inject the code. The audit evaluates the CSP and validates its real-world effectiveness.
Can price-tampering tests be carried out without generating real orders?
Yes. The tests are run in a staging environment with test data. No real orders are generated and no payments are processed during the pentest.
I suspect I already have a skimmer. Where do I start?
By not deleting anything. Before cleaning up, preserve a copy of the current state: files, database and server logs, because they are the only evidence of how the attacker got in and since when. Then compare the scripts the production checkout loads against those that should be there, review recently modified files with no associated deployment, look for administrators created outside process, and check overrides and scheduled tasks. Cleaning without establishing the entry path guarantees reinfection.
Can the checkout be audited in production?
The observation part, yes, and it is in fact the only way to see what the real checkout loads: scripts, headers, CSP and gateway behaviour in test mode. What is not done in production is price tampering or active injection testing, which runs against staging with test data and without processing payments.
Is a tag manager on the checkout a risk?
It is a first-order risk, because it allows arbitrary JavaScript to be injected into the payment page without passing through the deployment cycle or code review, and usually with marketing staff holding access. If it stays on the checkout, the container must be restricted to approved tags, with control over who can publish and with publications logged. The safest option is simply not loading it on payment pages.
What is delivered after a checkout audit?
The real inventory of scripts executing on the payment page with their origin, the results of price and coupon tampering tests with proof of concept, the assessment of the gateway integration (signatures, tokens and logging), the analysis of the content security policy and its practical effectiveness, and a remediation plan ordered by business impact.