E-commerce Checkout Security UK — Protecting Payments and Customer Data

The Most Attacked Page on Your Website

If you run an e-commerce website, your checkout page is the most valuable target on your entire domain. It's where payment data flows, where customers are authenticated, and where the business logic that governs discounts, stock levels, and order creation lives.

Attackers know this. In the UK, Magecart-style payment skimming attacks — where malicious JavaScript harvests card details as customers type them — remain one of the most common threats to e-commerce businesses. The attackers are not always breaking into your systems directly; sometimes they compromise a JavaScript library or analytics tool that your checkout page loads.

This guide explains the key checkout security risks for UK e-commerce businesses and what to do about them.

Magecart and Digital Skimming

Magecart refers to a category of attack (now associated with dozens of criminal groups) where malicious JavaScript is injected into checkout pages to capture payment card data. The JavaScript intercepts keystrokes as customers type their card number, CVV, and expiry date, and silently sends the captured data to an attacker-controlled server.

How does the malicious JavaScript get onto your site? Several routes:

**Direct compromise** — Your CMS, admin panel, or server is breached directly, and the attacker modifies your checkout template or JavaScript files.

**Supply chain compromise** — A third-party JavaScript library, advertising tag, or analytics tool you load on your checkout page is compromised. Your site loads their code, which is now malicious.

**Plugin or extension compromise** — A WooCommerce plugin or Magento extension you installed is abandoned by its developer, bought by a malicious actor, or directly compromised.

Mitigation

- Implement a strict **Content Security Policy (CSP)** that explicitly whitelists which external domains are allowed to load JavaScript on your checkout page. An unexpected JavaScript file from an unknown domain cannot execute. - Use **Subresource Integrity (SRI)** for any external JavaScript your checkout loads. SRI embeds a hash of the expected file, and the browser refuses to execute it if the content has changed. - Conduct regular **file integrity monitoring** of your checkout templates and JavaScript assets. - Load only the JavaScript you absolutely need on your checkout page. Every third-party script is a potential supply chain attack vector.

PCI DSS Requirements for UK Merchants

If your site accepts card payments, you are subject to the Payment Card Industry Data Security Standard (PCI DSS), regardless of size. Most UK small e-commerce businesses are under SAQ (Self-Assessment Questionnaire) scope.

Which SAQ applies depends on how you handle payment data:

**SAQ A** — You use a fully hosted payment page (Stripe Checkout, PayPal, Shopify Payments) and never handle card data on your own servers. The lightest compliance burden.

**SAQ A-EP** — You use an iframe or redirect to a payment processor but have JavaScript running on your checkout page (common with WooCommerce and Stripe Elements). Requires annual penetration testing.

**SAQ D** — You store, process, or transmit card data directly. The most demanding compliance path — appropriate for very few SMEs.

Most UK small businesses should aim for SAQ A or A-EP by using a hosted payment solution. If you are on SAQ A-EP or higher, annual web application penetration testing is a requirement, not a recommendation.

Business Logic Vulnerabilities in Checkout

Beyond payment skimming, checkout pages frequently contain business logic vulnerabilities that allow attackers to manipulate prices, discount codes, or stock levels.

Price Manipulation

In some implementations, the product price is sent from the browser to the server as part of the checkout request. An attacker can intercept and modify this request to pay £0.01 for a £500 item.

The fix: **never trust client-submitted prices**. The server should look up the current price from your product database for every order, ignoring any price submitted by the client.

Discount Code Abuse

- **Unlimited use codes** — Codes intended for single use can sometimes be used repeatedly if the check is only on the frontend. - **Stacking exploitation** — Applying multiple discount codes simultaneously to achieve unintended discounts. - **Code enumeration** — Brute-forcing short discount codes to discover valid ones.

Race Conditions in Stock Management

If your application checks stock availability and then processes the order in two separate steps, a race condition may allow two customers to simultaneously purchase the last item — or an attacker to intentionally trigger this to oversell stock.

Coupon and Voucher Replay

Vouchers applied to one user's session replayed against another user's session. If your voucher validation is session-based but not tied to a specific user account, attackers can reuse vouchers across accounts.

Checkout Page Security Headers

Every checkout page should have:

**Content Security Policy** — Strict whitelist of allowed JavaScript sources.

**X-Frame-Options: DENY** — Prevents your checkout from being framed in a clickjacking attack.

**Strict-Transport-Security** — Forces HTTPS and prevents SSL stripping attacks.

**Cache-Control: no-store** — Prevents checkout page content (including partially entered card data) from being cached in browser history or shared caches.

Running Yrzo AI's security scanner against your checkout page will surface any missing security headers, identify whether your CSP is adequately restrictive, and flag common misconfigurations.

What PCI DSS Penetration Testing Requires

For merchants in SAQ A-EP or higher PCI DSS scope, annual penetration testing must:

- Cover all in-scope e-commerce web application components - Test for OWASP Top 10 and payment-specific vulnerabilities - Be conducted by a qualified tester (internal or external) - Produce a report showing vulnerabilities found and remediation status

Automated scanning tools can satisfy some of this requirement but typically cannot replace a manual penetration test for PCI purposes. However, automated scanning is valuable as an interim measure between annual tests and for post-remediation verification.

The SSL Certificate Is Not Enough

Many e-commerce businesses believe that having HTTPS and a padlock icon means their checkout is secure. The SSL certificate encrypts data in transit between your customer's browser and your server — but it says nothing about:

- Whether your application has injection vulnerabilities - Whether there is malicious JavaScript running on the page - Whether your payment processing logic can be manipulated - Whether your admin panel is protected against unauthorised access

HTTPS is a baseline, not a security programme. UK e-commerce businesses processing payments need regular security testing to understand the true state of their checkout security.