Ecommerce Security Scanner

Where Store Breaches Actually Start

Most ecommerce compromises do not begin with someone breaking the database. They begin with something the browser loads, or something the server left lying around.

Checkout and payment pages

The payment page is the one page where a customer types a full card number. If your store renders the card fields itself, any script on that page can read them. If it uses an iframe or hosted fields from your payment provider (Stripe Elements, Adyen, Braintree and similar), the card data stays inside the provider's frame. A script on the parent page can still swap the iframe for a fake form, though, so the parent page matters too.

Third-party scripts

A typical store loads a tag manager, analytics, a chat widget, review badges, A/B testing and retargeting pixels. Each one runs with full access to the page. If one of those vendors is compromised, or a tag manager account is taken over, the attacker's code ships to your checkout without a single change to your own repository. That is the Magecart pattern, and it is why script inventory and integrity are now explicit PCI DSS requirements.

Admin panels and leftover files

The other common entry point is plain exposure: an admin login on a default path with no IP restriction or second factor, a backup.sql from the last migration, a zipped copy of the site, or an .env file with payment and email API keys. None of these need an exploit. Someone only has to request the URL.

PCI DSS 4.0: Requirements 6.4.3 and 11.6.1

PCI DSS 4.0 added two requirements aimed squarely at skimming. Both were best practice until 31 March 2025 and are mandatory from that date.

• 6.4.3 covers every script that loads and runs on the payment page in the customer's browser. You need a way to confirm each script is authorized, a way to check its integrity, and a written inventory with a business reason for each one.
• 11.6.1 requires a change and tamper detection mechanism that alerts staff to unauthorized changes to the payment page's security-relevant HTTP headers and content, as received by the browser. It must run at least weekly, or at a frequency set by your targeted risk analysis.

In January 2025 the PCI Security Standards Council revised SAQ A. Merchants that fully outsource the payment page through an iframe or redirect no longer validate 6.4.3 and 11.6.1 directly. Instead they must confirm that their own site is not susceptible to script attacks that could affect the payment flow. If you cannot confirm that, you are not eligible for SAQ A and fall back to SAQ A-EP, which is much longer. In practice, a strict CSP and a short, known list of scripts on the page that hosts the iframe is how most merchants back up that confirmation.

A one-time scan does not satisfy 11.6.1, which asks for ongoing detection. Our free scan is also not an ASV scan, the quarterly external scan from an Approved Scanning Vendor that PCI DSS requirement 11.3.2 calls for. Use it to find and fix gaps before those formal checks, not in place of them.

Platform Notes: Shopify, WooCommerce and Magento

Shopify

Shopify hosts and runs the checkout, and its checkout extensibility model has replaced free-form checkout.liquid edits, so merchants have far less room to add arbitrary scripts there. Your storefront theme, installed apps and tracking pixels are still your responsibility. Review which apps inject scripts into the theme and remove the ones you no longer use.

WooCommerce

WooCommerce is a WordPress plugin, so the store inherits WordPress risk: outdated plugins and themes, an exposed wp-login.php, XML-RPC, and backup copies of wp-config.php. Whether card data touches your server depends on the payment gateway. Gateways that use hosted fields or redirects keep the card number off your pages. Our WordPress scanner page covers the WordPress side in more depth.

Magento and Adobe Commerce

Self-hosted Magento puts patching entirely on you, and Magento stores are a long-standing skimming target. CVE-2024-34102 (known as CosmicSting), an XML external entity flaw fixed in Adobe's June 2024 security update, was exploited at scale against stores that had not patched. Keep the admin on a custom path behind IP allow-listing and two-factor authentication, and apply Adobe security bulletins as soon as they are released.

What the Free Scan Checks on Your Store

The scan tests the URL you submit, path included. Scan your homepage first, then run a second scan on your cart or checkout URL if it is served from your own domain. Headers, cookies and page scripts can differ from page to page.

• TLS protocol versions and cipher suites, flagging TLS 1.0 and 1.1 as high risk, plus certificate chain problems.
• Security headers on the scanned page, including whether a Content-Security-Policy and HSTS are set.
• External scripts and stylesheets loaded without a Subresource Integrity hash.
• Mixed content: HTTP resources loaded on an HTTPS page.
• Forms that submit over plain HTTP or have no visible CSRF token.
• Secure, HttpOnly and SameSite flags on every cookie the page sets.
• JavaScript libraries loaded from CDNs at versions with known vulnerabilities.
• Exposed login and admin paths, database dumps, backup archives, .env files and .git directories.
• CORS misconfigurations and risky HTTP methods such as TRACE and PUT.

What it does not do: it does not log in, place test orders or step through a multi-page checkout, and it does not analyze script behavior to spot a live skimmer. It shows you the gaps a skimmer would use, such as no CSP and unpinned third-party scripts, so you can close them.

A Starting Point for Checkout CSP and SRI

A Content-Security-Policy limits where scripts can load from and where the page can send data. For a checkout using Stripe Elements, a starting policy looks like this:

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

The connect-src line is the one that hurts skimmers most, because it blocks the request that would carry card data to an outside server. Roll it out with Content-Security-Policy-Report-Only first and watch the reports for a few days before you enforce it.

For static third-party files, pin the exact version with an integrity hash so the browser refuses a modified copy:

<script src="https://cdn.example.com/lib@3.2.1/lib.min.js"
        integrity="sha384-<hash of that exact file>"
        crossorigin="anonymous"></script>

SRI does not work for scripts that change on every request, such as most tag managers and payment SDKs. Keep those off the payment page where you can, and cover the rest with CSP. The CSP Generator helps you draft a policy, and our security headers guide explains each directive.