Stop card skimmers on your checkout

How skimmers get in

• A vulnerable plugin or theme lets an attacker add a script to your pages or database.
• A third-party script you load (chat, analytics, reviews) is itself compromised.
• A stolen admin password lets someone paste a script into the theme or a “custom code” box.

1. Inventory every script on checkout

List each script on the cart and checkout pages, who owns it and why it’s needed. Remove the rest. This is exactly what PCI DSS v4.0 requirement 6.4.3 asks for.

2. Use hosted payment fields

Payment gateways that render card fields in their own iframe (for example Stripe’s Payment Element or PayPal’s hosted fields) keep card numbers off your page. Skimmers can still inject a fake form, so keep the other layers too.

3. Lock down checkout with CSP

Limit where scripts can load from and, just as important, where they can send data (connect-src, form-action):

Content-Security-Policy: default-src 'self'; script-src 'self' https://js.stripe.com; frame-src https://js.stripe.com; connect-src 'self' https://api.stripe.com; form-action 'self'; object-src 'none'; base-uri 'self'

4. Pin third-party files with SRI

For static files from a CDN, Subresource Integrity makes the browser refuse a changed file:

<script src="https://cdn.example.com/lib.min.js"
        integrity="sha384-REPLACE_WITH_THE_FILE_HASH"
        crossorigin="anonymous"></script>

Payment SDKs that change often (such as Stripe.js) can’t be pinned this way. Use CSP for those.

5. Detect changes

PCI DSS v4.0 requirement 11.6.1 asks for a way to detect unauthorised changes to payment page scripts and headers. HackGrade’s Pro deep scan watches checkout scripts for new sources, changes, inline code that sends data out and fake payment forms.

6. Stop card testing

Bots use weak checkouts to test stolen cards. Turn on your payment provider’s fraud tools, add a CAPTCHA or rate limit to checkout, and watch for bursts of small failed orders.