E-Commerce Security Checklist: PCI DSS, Magecart, DMARC & More

E-Commerce Security Checklist: PCI DSS, Magecart, DMARC & More

E-commerce security covers more ground than any other web security category. Your store is simultaneously a payment environment (PCI DSS scope), a handler of personal data (GDPR/CCPA scope), a target for skimming malware (Magecart), a brand that attackers impersonate (DMARC scope), and a fraud target (account takeover, payment fraud). Failing any one layer exposes your customers and your business.

This checklist covers the full stack: HTTPS and TLS, PCI DSS web requirements, client-side script protection against Magecart, email authentication, cookie security, and fraud controls.

Check your compliance posture: Free ZeriFlow security scan →

Layer 1: HTTPS and TLS — The Non-Negotiable Foundation

Every e-commerce site must enforce HTTPS on every page — not just checkout. Attackers inject code at any point in a browsing session, and a user whose session cookie is captured on the homepage is compromised even if checkout is encrypted.

HTTPS enforcement checklist:

• [ ] HTTP-to-HTTPS redirect on all pages (not just /checkout)
• [ ] Strict-Transport-Security header with max-age=31536000; includeSubDomains; preload
• [ ] TLS 1.2 minimum; TLS 1.3 preferred
• [ ] TLS 1.0 and 1.1 disabled
• [ ] RC4, DES, 3DES, and export cipher suites disabled
• [ ] Valid certificate from a trusted CA, renewed before expiry
• [ ] Certificate covers all subdomains used by the store (wildcard or SAN certificate)
• [ ] No mixed content (HTTP resources on HTTPS pages)
• [ ] Certificate Transparency monitoring enabled

Why this matters for PCI DSS: Requirement 4 mandates encryption in transit. Expired certificates, protocol downgrades, and mixed content are direct PCI failures. PCI DSS 4.0 prohibits TLS 1.0/1.1.

Layer 2: PCI DSS Web Requirements for Online Stores

PCI DSS scoping for e-commerce depends on your integration method, but the web layer is always in scope. The most critical requirements at the website level:

Checkout page isolation: - [ ] Checkout is hosted on a single, identifiable URL (or subdomain) - [ ] Checkout page loads no third-party scripts except those with documented business justification - [ ] All third-party scripts on checkout pages are loaded with Subresource Integrity (SRI) hashes or CSP hash/nonce values (PCI DSS 4.0 Requirement 6.4.3) - [ ] A change detection mechanism is in place to alert on unauthorized modifications to checkout scripts or HTTP headers (Requirement 11.6.1)

Payment method: - [ ] If using hosted payment pages (Stripe Checkout, Braintree redirect): SAQ A scope applies - [ ] If using embedded payment fields (Stripe Elements, Braintree Drop-in): SAQ A-EP scope applies; script integrity controls mandatory - [ ] No cardholder data (full PAN, CVV, expiry date) stored anywhere in your application

Access and logging: - [ ] Admin access to payment-related systems protected by MFA - [ ] Payment-related application events logged with timestamps - [ ] Logs retained for 12 months minimum

Layer 3: Content Security Policy — Your Defense Against Magecart

Magecart is the category of attack that has compromised British Airways, Ticketmaster, Macy's, and thousands of smaller merchants. The attack vector: a malicious script is injected into a checkout page (via a compromised third-party vendor, a CDN compromise, or a direct site compromise), and the script silently exfiltrates card numbers to attacker-controlled servers.

A properly configured Content Security Policy is the most effective technical defense against Magecart. It prevents unauthorized scripts from executing, even if they are injected.

CSP checklist for e-commerce:

• [ ] Content-Security-Policy header deployed on all pages (not report-only mode in production)
• [ ] script-src directive explicitly lists approved scripts; no unsafe-inline or *
• [ ] Checkout page has the most restrictive CSP — ideally only first-party scripts plus payment provider
• [ ] Payment provider scripts loaded with SRI hashes (verify when the provider releases updates)
• [ ] connect-src restricts where JavaScript can send data (blocks exfiltration to unauthorized domains)
• [ ] form-action restricts where forms can submit (prevents form hijacking)
• [ ] CSP violations reported to a CSP report endpoint for monitoring
• [ ] CSP reviewed and updated when new third-party scripts are added

Subresource Integrity (SRI) checklist:

• [ ] All externally hosted JavaScript loaded with integrity="sha256-..." attribute
• [ ] SRI hashes updated when vendor scripts are updated
• [ ] Bootstrap, jQuery, and other CDN-hosted libraries use SRI

Layer 4: Cookie Security — Protecting Sessions and Preferences

E-commerce sites use cookies for session management, cart persistence, authentication, and tracking. Insecure cookies are a direct attack vector: session hijacking, cross-site request forgery, and tracking data leakage.

Cookie security checklist:

• [ ] Session cookies set with Secure flag (cookie only transmitted over HTTPS)
• [ ] Session cookies set with HttpOnly flag (not accessible to JavaScript)
• [ ] Session cookies set with SameSite=Strict or SameSite=Lax (CSRF mitigation)
• [ ] Cookie expiry appropriate for sensitivity: session cookies for authentication, longer expiry for cart/preference only
• [ ] No sensitive data stored in cookie values (order IDs, partial card numbers, user data)
• [ ] Cookie consent mechanism compliant with GDPR/CCPA as applicable
• [ ] Global Privacy Control (GPC) honored for California visitors

ZeriFlow checks all cookie attributes on your site — Secure, HttpOnly, SameSite — and surfaces cookies that are missing protective flags.

Layer 5: DMARC and Email Authentication — Protecting Your Brand

E-commerce brands are high-value targets for email spoofing. Attackers send phishing emails purporting to be from your store: fake order confirmations, "account security alerts," or shipping notifications designed to harvest credentials or payment data.

Email authentication does not protect your website directly — it protects your customers from emails that impersonate you.

Email authentication checklist:

• [ ] SPF record published in DNS (authorizes which servers may send email as your domain)
• [ ] DKIM signing configured for all email senders (ESP, transactional email service, marketing platform)
• [ ] DMARC policy published: v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com
• [ ] DMARC policy is p=reject (not p=none or p=quarantine) — p=none provides monitoring but no protection
• [ ] BIMI record configured (optional but strengthens brand trust in supported email clients)
• [ ] All third-party email senders (Klaviyo, Mailchimp, Zendesk, Shopify) authorized in SPF and signing with DKIM
• [ ] DMARC aggregate reports reviewed monthly to catch unauthorized senders

ZeriFlow checks your SPF, DKIM, and DMARC configuration as part of its DNS security checks, identifying common misconfigurations such as p=none policies, missing DKIM alignment, and SPF records that exceed the 10-DNS-lookup limit.

Layer 6: Security Headers for E-Commerce

Security headers are HTTP response headers that instruct the browser to apply protective behaviors. For e-commerce sites:

Security header checklist:

• [ ] Content-Security-Policy — (see Layer 3 above)
• [ ] Strict-Transport-Security — HSTS with preload flag
• [ ] X-Frame-Options: DENY or Content-Security-Policy: frame-ancestors 'none' — prevents your checkout from being embedded in attacker-controlled iframes
• [ ] X-Content-Type-Options: nosniff — prevents MIME type sniffing
• [ ] Referrer-Policy: strict-origin-when-cross-origin — limits referrer data sent to third parties
• [ ] Permissions-Policy — restricts access to browser APIs (camera, microphone, geolocation, payment) on pages that do not need them
• [ ] No Server header exposing web server version
• [ ] No X-Powered-By header exposing framework version

Layer 7: Fraud Controls and Account Security

Payment fraud and account takeover are operational security concerns for e-commerce that sit above the protocol layer but are equally important.

Account security checklist:

• [ ] Multi-factor authentication available for customer accounts (optional for customers, mandatory for admin)
• [ ] Rate limiting on authentication endpoints (login, password reset, account creation)
• [ ] Credential stuffing protection (IP reputation, device fingerprinting, or a bot management solution)
• [ ] Breached password detection at account creation and password reset
• [ ] Account lockout after N failed login attempts
• [ ] Suspicious login alerting (new device, new location, impossible travel)

Payment fraud checklist:

• [ ] 3DS2 (3D Secure v2) enabled for applicable card payments
• [ ] Address Verification Service (AVS) and CVV checks enforced
• [ ] Order velocity rules (flag multiple orders from one IP/device in short window)
• [ ] Shipping address anomaly rules (mismatches between billing and shipping countries)
• [ ] Chargeback rate monitoring and triggering fraud review when threshold exceeded

FAQ

Q: Do I need PCI DSS compliance if Shopify handles all my payments?

A: Shopify's hosted checkout means payment data is processed entirely on Shopify's infrastructure, not yours. You would typically qualify for PCI DSS SAQ A — the simplest questionnaire, covering approximately 22 requirements focused on your website's security posture (HTTPS, access controls to Shopify admin) rather than payment processing. However, if you add third-party scripts to your checkout page (via Shopify scripts, Google Tag Manager, or any app that injects JavaScript on checkout pages), you must consider whether those scripts could access form data, potentially moving you toward SAQ A-EP requirements.

Q: What is a Magecart attack and how do I know if my site is infected?

A: Magecart attacks inject JavaScript onto checkout pages that silently reads card numbers, CVV codes, and billing addresses as customers type them, then transmits the data to attacker-controlled servers. Detection: review your checkout page's loaded scripts against your known script inventory; look for unfamiliar domains in network requests from checkout pages; use a browser with your site's CSP enabled and watch for CSP violation reports; monitor your server-side access logs for unusual requests. ZeriFlow's script monitoring checks can help identify unexpected third-party resources on your pages.

Q: Is DMARC p=reject safe to deploy without breaking email?

A: Deploying p=reject without a transition phase can break legitimate email. The recommended approach: start with p=none to collect DMARC aggregate reports for 4-8 weeks, identify all legitimate senders and ensure they have SPF and DKIM configured correctly, move to p=quarantine (failed emails go to spam instead of being rejected) for 2-4 weeks, then move to p=reject. Most email deliverability problems at the p=reject stage are caused by third-party senders (newsletters, transactional email, support platforms) that are not in your SPF record or are not signing with DKIM.

Q: Do SameSite cookies break cross-domain cart functionality?

A: SameSite=Strict can break cross-domain flows where a user navigates from an external site to your store and expects their cart or session to persist. SameSite=Lax is a safer choice for most e-commerce session cookies: it allows cookies in top-level navigation (following a link) but blocks them in cross-site requests that load embedded resources. For true cross-domain integrations (subprocessor checkouts, multi-storefront implementations), SameSite=None; Secure is required — but this should only be used for specific integration cookies, not session cookies.

Q: How often should I audit my CSP for e-commerce?

A: Audit your CSP any time you add a new third-party script to your site, when a third-party vendor releases a major update to their script URL or hash, and at minimum quarterly as a scheduled review. CSP can drift over time as marketing teams add tracking pixels, affiliate scripts, and chat widgets — often without informing the security or engineering team. Automated monitoring of your checkout page's loaded scripts against a known-good baseline is the most reliable way to catch unauthorized additions.

Conclusion

E-commerce security is a layered discipline. The checkout page sits at the intersection of PCI DSS compliance, Magecart prevention, session security, and fraud controls — all of which require different technical controls at different layers of the stack.

The most common e-commerce security failures are preventable with configuration: missing HSTS, absent CSP on checkout pages, DMARC at p=none, and session cookies without Secure or HttpOnly flags. These are not engineering challenges — they are operational gaps that automated scanning surfaces in seconds.

Run a free compliance-focused scan on ZeriFlow →