The Ecommerce Website Security Checklist Hackers Hope You Skip

Ecommerce sites are the highest-value target on the open web. A single skimmer injected into your checkout page can quietly harvest card details for months before anyone notices. Magecart attacks, credential stuffing, coupon abuse, and supply-chain compromises through third-party scripts are all routine — and most of them exploit misconfigurations rather than zero-days.

This is the ecommerce website security checklist we actually use when auditing online stores. It's ordered roughly by risk-to-effort ratio, so the early items give you the biggest wins.

1. Lock down TLS and certificates

TLS is table stakes, but "we have HTTPS" isn't enough. A surprising number of stores still serve TLS 1.0/1.1, weak ciphers, or expired intermediate certificates.

• Disable TLS 1.0 and 1.1. Require TLS 1.2 minimum, prefer TLS 1.3.
• Use strong ciphers only — disable RC4, 3DES, and CBC suites where possible.
• Set up automated certificate renewal (Let's Encrypt, ACM, or your CDN's managed cert).
• Enable HSTS with a long max-age once you're confident: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
• Submit your domain to the HSTS preload list once everything subdomain-wide is HTTPS.

Watch the certificate chain

Browsers complain when intermediate certs aren't served. Test from multiple regions — issues sometimes only appear on specific CDN edges.

2. Ship the security headers that actually matter

Security headers are free and stop entire classes of attack. The non-negotiables for an ecommerce site:

• Content-Security-Policy — stops injected scripts (the #1 Magecart defense)
• Strict-Transport-Security — forces HTTPS
• X-Content-Type-Options: nosniff — blocks MIME confusion
• Referrer-Policy: strict-origin-when-cross-origin — leaks fewer URLs to third parties
• Permissions-Policy — disable APIs you don't use (camera, geolocation, payment if not needed on that page)

If you're not sure which of these are missing, run your store through WebSentry — it grades each header and shows the exact response you're serving.

3. Build a CSP that survives a third-party compromise

Most Magecart attacks succeed because the site loads dozens of third-party scripts (analytics, chat widgets, tag managers, A/B tools) with no restriction. A proper CSP is the single best defense.

A realistic starting CSP for ecommerce

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{random}' https://js.stripe.com;
  style-src 'self' 'nonce-{random}';
  img-src 'self' data: https://cdn.shopify.com;
  connect-src 'self' https://api.stripe.com;
  frame-src https://js.stripe.com https://hooks.stripe.com;
  form-action 'self';
  frame-ancestors 'none';
  base-uri 'self';
  upgrade-insecure-requests;
  report-uri /csp-report

• Use nonces or hashes instead of 'unsafe-inline'.
• Deploy in Content-Security-Policy-Report-Only first, watch the reports for a week, then enforce.
• Pin payment iframes (Stripe, Adyen, Braintree) and nothing else under frame-src.

4. Harden the checkout flow specifically

The checkout page deserves stricter rules than the rest of the site.

• Use a hosted payment iframe (Stripe Elements, Adyen Web Components) so card data never touches your server.
• Apply Subresource Integrity (SRI) to every external script: <script src="..." integrity="sha384-..." crossorigin="anonymous">
• Consider a separate, minimal CSP just for /checkout that disallows analytics and chat widgets.
• Set Cache-Control: no-store on any page that renders order or customer data.

5. Cookie hygiene

Session cookies are the keys to every customer account.

• Secure — never sent over HTTP
• HttpOnly — not readable by JavaScript
• SameSite=Lax minimum, Strict for session cookies where possible
• Prefix sensitive cookies with __Host- to lock them to the exact host over HTTPS
• Rotate session IDs on login and on privilege escalation

6. DNS and email authentication

Attackers often skip the website entirely and go after your domain or your customer-facing email.

• DNSSEC — enable it at your registrar if your DNS provider supports it.
• CAA records — restrict which CAs can issue certs for your domain: example.com. CAA 0 issue "letsencrypt.org"
• SPF, DKIM, DMARC — a p=reject DMARC policy stops attackers spoofing your order-confirmation emails.
• Lock the registrar account with MFA and registry-lock if your registrar offers it.

7. Authentication and admin access

• Enforce MFA for every admin, developer, and support user — no exceptions.
• Rate-limit login endpoints aggressively. Stuffing attacks try thousands of stolen credentials per minute.
• Use a separate admin subdomain or path with IP allowlisting where feasible.
• Don't email password reset links over plain HTTP redirects — verify the full chain stays HTTPS.
• Set a sensible password policy (long minimums, breach-list checks via HaveIBeenPwned's k-anonymity API).

8. Manage your third-party script inventory

Walk through your store with browser devtools open and list every domain that loads. For each one ask:

1. Do we still need this script?
2. Does it load on the checkout page? Can we move it to other pages only?
3. Is it pinned with SRI?
4. Who at the vendor has push access to that JS bundle?

Tag managers are particularly dangerous — anyone with GTM access can effectively inject arbitrary JavaScript into your store. Audit GTM users quarterly.

9. Keep platforms and dependencies patched

• Magento, WooCommerce, Shopify apps, and PrestaShop modules all have a history of critical CVEs. Subscribe to security advisories.
• Run npm audit / composer audit in CI and fail builds on high-severity issues.
• Pin dependency versions and use a lockfile. Never latest in production.
• For self-hosted platforms, patch within 72 hours of a critical advisory.

10. Logging, monitoring, and incident response

• Log all admin actions, failed logins, and price/discount changes.
• Set alerts for unusual order patterns (gift cards bought with mismatched IPs, multiple cards on one account).
• Enable CSP reporting to a real endpoint — don't fire and forget.
• Write a one-page incident playbook: who isolates the server, who rotates keys, who calls the payment processor.

11. Backups you've actually tested

• Daily database backups with at least 30 days retention.
• Off-site, encrypted, and immutable (so ransomware can't delete them).
• Restore-test quarterly. A backup you've never restored isn't a backup.

Run the scan

Most of this checklist can be verified externally in under a minute. Drop your store's URL into WebSentry for a free scan — you'll get an A–F grade across SSL, headers, CSP, cookies, DNS, and CORS, with the exact misconfigurations called out so you can fix them before your next deploy.