E-commerce Site Security Checklist: 30 Checks for Online Stores

Online stores attract attackers for a simple reason: they handle logins, personal data and payments. You do not need an enterprise security team to cover the basics, but you do need a list and the discipline to review it regularly. This checklist is grouped by area, starts with the highest-impact items and notes how to verify each one from the outside. Where the platform handles something for you (a hosted checkout, for example), the checklist says what remains your responsibility.

1. Know what you are responsible for

• Hosted checkout (Shopify Checkout, a provider's redirect or fully hosted payment page): the card details never touch your server, which narrows your scope considerably. You still own your admin accounts, your theme and apps, your DNS and your customer data.
• Embedded payment fields (hosted fields or iframes served by the provider inside your page): your page still loads the script that renders them, so your page integrity matters.
• Card data on your own server: this brings the heaviest obligations. Avoid it unless you have a strong reason and a compliance plan.

Payment card standards are published by the PCI Security Standards Council. The current version includes requirements about managing scripts on payment pages and detecting changes to them, so ask your payment provider which requirements apply to your integration type.

2. Transport security (verify from outside)

1. HTTPS everywhere, with HTTP redirecting to HTTPS in one hop. Test with the SSL Checker.
2. Valid certificate chain and automatic renewal. Expiry takes shops down and trains customers to click through warnings. See renew SSL and automate it.
3. Modern TLS versions only. Check support with the TLS Version Checker and retire old protocol versions if your host allows it.
4. HSTS once HTTPS is stable. Verify with the HSTS Checker. Start with a short lifetime and increase it; see HSTS preload guide before considering preload.
5. No mixed content on any page, especially cart and checkout. Scan with the Mixed Content Checker.
6. Secure cookies. Session and auth cookies should carry Secure and HttpOnly, and an appropriate SameSite value. Inspect them with the Cookie Checker; see cookie flags guide.

3. HTTP security headers

Set these where your platform allows it. On hosted platforms you may control only some of them.

Grade your current setup with the Security Headers Checker. A CSP on a store has to allow your payment provider, analytics and every app script, so roll it out in report-only mode first and tighten gradually. Content security policy guide and HTTP security headers guide explain how.

4. Third-party scripts: the e-commerce blind spot

Attacks that steal card details from checkout pages usually do not break into the server. They compromise a script the page already loads, such as a chat widget, tag manager entry, analytics snippet or app. Treat every third-party script as code you are letting run inside your checkout.

1. Inventory scripts. Run the Third-Party Script Checker on home, product, cart and checkout pages and write down who owns each one.
2. Remove what you do not use. Old pixels and abandoned apps are risk with no benefit.
3. Keep non-essential scripts off the payment page. Marketing tags rarely need to run on the step where card details are entered.
4. Use Subresource Integrity (SRI) for scripts loaded from a CDN that you can pin to a fixed version. It does not help with dynamic vendor tags that change often.
5. Restrict tag manager access. Whoever can publish a tag can run code on your site. Use named accounts, two-factor authentication and review changes.
6. Alert on script changes. A CSP report endpoint or a periodic script inventory comparison gives you early warning.

5. Accounts and access

1. Two-factor authentication for every admin, staff and developer account on the platform, the host, the DNS provider, the domain registrar, the email provider and the payment dashboard.
2. Unique passwords in a password manager. Reused passwords from other breaches are how many stores are taken over.
3. Least privilege. Staff get the minimum role they need. Agencies and freelancers get time-limited access that you remove afterward.
4. Remove old users and API tokens when people leave or integrations are retired.
5. Rename or restrict admin entry points where it is practical, and rate-limit login attempts. On WordPress, see WordPress security hardening checklist.
6. Protect the domain registrar and DNS account with the strongest controls you have. Someone who can change DNS can intercept your traffic and your email. Registrar lock helps against unauthorized transfers; see domain transfer guide.

6. Software and dependencies

1. Update the platform, theme and plugins promptly, testing on staging first. For self-hosted stores, include PHP, the web server and the operating system.
2. Remove unused plugins and themes rather than just deactivating them.
3. Vet apps and plugins before installing: recent updates, developer reputation, requested permissions and reviews. Install fewer, better-maintained ones.
4. Do not run abandoned software. If an extension has not been updated in a long time and the vendor is silent, plan its replacement.
5. Keep file permissions tight and prevent PHP execution in upload directories on self-hosted sites.

7. Data protection and backups

1. Back up automatically to a location that an attacker who owns the server cannot also delete, and test restoring one. WordPress site hacked recovery explains why untested backups fail you at the worst moment.
2. Collect only the customer data you need, and delete what you no longer need. Data you do not store cannot leak.
3. Protect exports and reports. Order exports in email attachments and shared drives are a frequent leak.
4. Review privacy and breach obligations that apply in your markets, and know whom to notify if something does leak.

8. Bot, fraud and abuse controls

1. Rate-limit login, password reset, search, coupon and checkout endpoints. Card-testing bots hammer checkout with small transactions to find valid cards; your payment provider's fraud tools and a CAPTCHA or challenge on suspicious traffic help.
2. Use fraud screening offered by your payment provider and review high-risk orders before shipping.
3. Understand your DDoS posture. A CDN and WAF absorb most noise; see DDoS basics for website owners.

9. Monitoring and response

Security without detection is hope. Add these:

• Uptime and keyword monitoring for the checkout path, so defacement or broken pages are noticed. See payment gateway downtime monitoring.
• Blocklist monitoring. Hacked stores get flagged by search engines and email providers. Check the domain and sending IPs with the Blacklist Checker.
• Certificate and domain expiry alerts with the uptime monitor.
• DNS change alerts, since unexpected record changes can indicate an account compromise. Review dangling records too; see subdomain takeover and dangling DNS.
• Admin login alerts and logs retained for a sensible period.
• An incident plan: who isolates the site, who contacts the payment provider and host, who communicates with customers. Write it before you need it, and use the incident postmortem template afterward.

A review rhythm that works

• Monthly: updates, user and token review, backup restore test, header and script scan.
• Quarterly: access review for agencies and apps, DNS and registrar review, incident drill.
• Before peak sales: everything above plus the Black Friday readiness checklist.

Next steps

• Grade your headers with the Security Headers Checker.
• Inventory scripts with the Third-Party Script Checker.
• Check HTTPS with the SSL Checker and HSTS Checker.
• Watch for problems with the uptime monitor.
• Learn headers in depth: HTTP security headers guide.

FAQ

Is a hosted checkout enough to make my store secure?

It removes card data handling from your server, which is a large risk reduction, but you remain responsible for admin access, apps, your theme, DNS and customer data.

What is the most common way online stores get compromised?

Stolen or reused admin passwords and vulnerable or malicious plugins and scripts are among the most common routes. Two-factor authentication and a small, maintained set of extensions address both.

Do I need a CSP on my store?

It is strongly worthwhile because it limits what injected scripts can do, but it must be rolled out carefully. Begin in report-only mode, fix violations and then enforce.

How often should I run a security review?

A light monthly review and a deeper quarterly one work for most small stores, plus a full check before any major sale.

What should I do if I suspect a breach?

Take action quickly: change credentials, review admin users and recent changes, restore from a clean backup if needed, notify your payment provider and host, and follow any legal notification duties that apply to you.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.