Ecommerce Store Security Checklist

Online stores are usually breached through the admin login, an outdated plugin or a script injected into the checkout page, and the first sign is often a card brand or a customer reporting fraud weeks later. This template is a checklist for store owners and the people who run stores for them, covering admin access, platform and extension updates, payment page scripts under PCI DSS requirements 6.4.3 and 11.6.1, bots and card testing, fraud rules, customer accounts, and monitoring. It works for hosted platforms and self-hosted ones; platform notes cover Adobe Commerce (Magento), Shopify and WooCommerce, listed alphabetically. It is written for ecommerce managers, developers and agencies who maintain stores. For the wider threat picture in retail, read the Cybersecurity for Retail and Ecommerce Guide; this page is the checklist.

How to use this template

Run it once per storefront. Replace text in square brackets, such as [Organisation], [store URL], [payment provider] and [agency], with your own details.
Mark each line Pass, Fail, Exception (with the person who accepted the risk) or Not applicable with a reason. Keep evidence: screenshots of settings, the script inventory, and fraud rule exports.
Section 4 quotes PCI DSS v4.0.1. Which requirements apply to you depends on how card data reaches your payment provider and which Self-Assessment Questionnaire (SAQ) you validate against; confirm this with your acquirer or provider. The PCI DSS Readiness Checklist covers the full standard.
Hosted platforms run much of the infrastructure for you. Your responsibility still covers admin accounts, installed apps and extensions, scripts you add, and fraud settings.
Repeat the review every quarter, before peak trading periods, and after any new app, theme change or agency change.

1. Store record

Field	Value
Store and platform	[store URL], [Adobe Commerce / Shopify / WooCommerce / other], [version or plan]
Hosting and who manages it	[hosted by platform / host name], [agency or internal team]
Payment method integration	[redirect to provider / embedded iframe / provider JavaScript fields / direct post / own form]
PCI DSS validation	[SAQ A / SAQ A-EP / SAQ D / ROC], [acquirer]
Number of admin or staff accounts, apps or extensions installed	[numbers]
Reviewer and date	[name], [date]

2. Admin and staff access

Check	Result
Every admin and staff account uses two-step or multi-factor authentication, with security keys, passkeys or an authenticator app rather than SMS. PCI DSS 8.4.2 requires MFA for all non-console access into the cardholder data environment.	[ ]
Each person has their own named account; no shared logins, including for the agency and freelancers.	[ ]
Staff permissions follow least privilege: only [2] people can install apps or extensions, edit themes or code, or change payment settings.	[ ]
Accounts for leavers, past agencies and freelancers are removed; staff accounts reviewed each quarter. See the Employee Offboarding Security Checklist.	[ ]
Admin login is protected from automated guessing: lockout after failed attempts (PCI DSS 8.3.4 limits invalid attempts), CAPTCHA or bot protection, and where supported a non-default admin path.	[ ]
Hosting, DNS, domain registrar, email and payment provider dashboards also have MFA and named accounts, since any of them can take over the store.	[ ]
API keys and app tokens are owned, scoped to what each integration needs, and rotated when a developer or agency leaves. See the Shopify App Tokens Security Guide for one platform's model.	[ ]

3. Platform, apps and extensions

Check	Result
Platform core is on a supported version with current security patches; there is a named owner and a target of [14] days for security updates, faster for actively exploited flaws.	[ ]
Apps, plugins, extensions and themes come only from the official marketplace or a known developer; no nulled or pirated copies.	[ ]
Every installed app or extension has a business reason; unused ones are removed rather than disabled.	[ ]
Extensions are updated on the same cycle as core, and abandoned ones (no updates for [12] months) are replaced.	[ ]
Changes are tested on a staging copy first, and a tested backup or rollback point exists before every update.	[ ]
Self-hosted only: no development leftovers on the web server (exposed .git directories, database dumps, log files, phpinfo files).	[ ]

Platform notes (alphabetical)

Area	Adobe Commerce (Magento)	Shopify	WooCommerce
Admin MFA	Adobe lists 2FA for the Admin and all SSH connections as a priority recommendation.	Staff set up two-step authentication on their own accounts; the store owner cannot turn it on for another staff member. Shopify Plus organisations can require a secure sign-in method for all users.	WooCommerce guidance says to limit login attempts and enable 2FA for WordPress accounts.
Admin hardening	Non-default admin URL, Advanced security settings (secret key in URLs, session length, login attempt limits), reCAPTCHA, least privilege Admin roles.	Staff accounts and permissions managed in the Shopify admin; passkeys and security keys supported for sign-in.	Strong unique passwords, change the default `wp_` table prefix, disable XML-RPC and REST API access where not needed, secure file permissions.
Updates	Adobe typically releases security updates quarterly, with hotfixes for major threats; the Commerce Security Scan service monitors for known risks and malware.	Platform infrastructure is updated by Shopify; apps and theme code you add stay your responsibility.	Enable automatic updates for WordPress core; update WooCommerce, plugins and themes regularly.
Payment page scripts	Content Security Policy is built in; from 2.4.7 it runs in restrict mode by default on payment pages.	Review scripts added through apps, pixels and theme code against the inventory in section 4.	Review scripts added by plugins and themes against the inventory in section 4.
Further detail	Magento and Adobe Commerce security	Shopify Store Security	WooCommerce Security

4. Payment page scripts

Web skimming injects JavaScript into checkout pages to copy card details as customers type. PCI DSS v4.0.1 has two requirements for this, both mandatory since 31 March 2025 for the entities they apply to. In January 2025 the PCI Security Standards Council removed 6.4.3 and 11.6.1 from SAQ A and replaced them with an eligibility criterion that the merchant confirms its site is not susceptible to attacks from scripts that could affect its ecommerce systems, so SAQ A merchants still need to protect the page that hosts or redirects to the payment form.

Check	PCI DSS v4.0.1	Result
An inventory lists every script loaded on payment pages (yours, third party and fourth party), each with a written business or technical justification.	6.4.3	[ ]
A method confirms each script is authorised before it runs (or as soon as possible after a change where that is impractical).	6.4.3	[ ]
A method assures the integrity of each script, for example Subresource Integrity hashes, a Content Security Policy, or a script monitoring service.	6.4.3	[ ]
A change and tamper detection mechanism alerts staff to unauthorised changes to security-impacting HTTP headers and script contents of payment pages as received by the browser, running at least weekly or at the frequency set by a targeted risk analysis.	11.6.1	[ ]
Alerts from that mechanism go to a named person with a response plan. See the Web Skimming Incident Playbook.	11.6.1, 12.10	[ ]
Marketing tags, chat widgets and analytics are kept off payment pages unless they are in the inventory.	6.4.3	[ ]

The Subresource Integrity Guide and the Client-Side Script Protection Buyer's Guide cover integrity methods and tooling.

5. Bots, card testing and fraud rules

Threat	Check	Result
Card testing (criminals checking stolen cards with small orders)	CAPTCHA or bot protection on checkout and payment method forms; velocity limits per IP, device, card and email; alerts on spikes of declined authorisations. See the Card Testing and Carding Attacks Defence Guide.	[ ]
Credential stuffing on customer logins	Rate limits and bot protection on login and password reset; breached password checks where supported.	[ ]
Fake account creation and promotion abuse	Limits on accounts per device or payment method; single-use or capped discount codes.	[ ]
Fraudulent orders	Provider fraud rules on: 3-D Secure where supported, AVS and CVV mismatch rules, block or review lists, review queue for high-value or high-risk orders.	[ ]
Refund and chargeback abuse	Refunds only to the original payment method; approval needed above [amount]; chargeback rate tracked monthly.	[ ]
Rule maintenance	Fraud rules reviewed each month against false declines and chargebacks; changes logged.	[ ]

6. Customer accounts and data

Check	Result
The whole store runs over HTTPS with a valid certificate, and HTTP redirects to HTTPS.	[ ]
Card data is never stored by the store; payment tokens from the provider are used for saved cards.	[ ]
Customer personal data held is limited to what orders need, with a retention period of [period], and exports are restricted to named staff.	[ ]
Customers can use passkeys or MFA where the platform supports it; account email and password changes trigger a notification.	[ ]
Order confirmation and marketing email is sent from a domain with SPF, DKIM and DMARC. See the Email Authentication Checklist.	[ ]

7. Monitoring, backups and response

Check	Result
Admin activity logs are kept and reviewed for new staff accounts, app installs, theme and code edits, and payment setting changes.	[ ]
Self-hosted: file integrity monitoring and malware scanning run on the web root; alerts go to [owner].	[ ]
Backups of store data and code are taken [daily], kept off the server, and a restore was tested in the last [6] months.	[ ]
Contacts for the platform, host, payment provider and acquirer are recorded for incidents, and the team knows when to call each.	[ ]

8. Findings and sign-off

Finding	Severity	Owner	Due date
[finding]	[high / medium / low]	[name]	[date]

Sign-off: [store owner], [date].

Implementation guidance

What to do first: admin MFA and removing old accounts (section 2) stop the most common takeover route in an afternoon. Next, remove unused apps and update the rest (section 3). Then build the script inventory (section 4): it is slow the first time because tags arrive through apps, tag managers and themes, but it is the only defence against skimming that you control.

Testing and rollback: run a new Content Security Policy in report-only mode first, review the violations, and switch to enforcing once legitimate scripts stop appearing; Adobe describes the same report-only then restrict sequence. Test bot protection and fraud rules on a low-traffic period and watch conversion and false declines for a week; keep the previous rule set exported so you can restore it.

Small and large stores: a small store on a hosted platform with a redirect or iframe payment page can cover most of this with platform settings, the payment provider's fraud tools and a quarterly review. Larger or self-hosted stores need a script monitoring tool, a web application firewall or bot management service, central logging and a tested incident plan.

Metrics: admin accounts without MFA (target 0); days to apply security updates; unused apps or extensions (target 0); payment page scripts not in the inventory (target 0); card testing alerts per month; chargeback rate against your acquirer's threshold.

Common failures: an agency account with full rights kept after the contract ended; a plugin abandoned by its developer still running on checkout; a tag manager on the payment page letting marketing add scripts nobody reviews; fraud rules set once and never tuned; and backups stored on the same server that was compromised.

Checklist section	PCI DSS v4.0.1	NIST CSF 2.0	ATT&CK
Admin access (2)	8.3.4, 8.4.2	PR.AA-03	T1078 Valid Accounts
Platform and extensions (3)	6.3.3	ID.RA-01	T1190 Exploit Public-Facing Application
Payment page scripts (4)	6.4.3, 11.6.1	DE.CM-09	T1195 Supply Chain Compromise
Monitoring and response (7)	10.2, 12.10	DE.CM-09, RS.MA-01

Ecommerce Store Security Checklist: Checkout, Admin, Bots and Fraud Rules