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.
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.