Magento security checklist: practical checks for your store

Start with evidence, not a security score

1. Establish the store and responsibility baseline

• List each production domain, store view, admin entry point, staging environment and connected storefront. Include domains maintained by another supplier.
• Record the exact Commerce edition and version, hosting plan, deployed code revision, PHP version and relevant database, cache, search and queue services.
• Name the owner of application updates, infrastructure, DNS, certificates, backups and incident decisions. Record provider escalation contacts and who can authorise emergency work.
• Evidence to retain: the inventory, responsibility list and date each supplier confirmed its part. Mark unknowns as unresolved rather than assuming they are covered.

2. Verify security patches and supported dependencies

• Maintain a patch register containing the advisory, affected component, applicability decision, selected patch, test result and deployed revision.
• Check extensions and custom modules as well as core Magento. Assign an upgrade or replacement decision when a component is no longer maintained.
• Test applicable changes on representative staging, agree rollback criteria and verify the deployed files or supported patch-status output after release.
• Evidence to retain: installation output, production verification and a test record for checkout, payment, order confirmation and essential integrations. Make sure the next deployment retains the fix.

3. Review admin access and authentication

• Use named accounts and only the permissions each person needs. Remove departed staff and expired supplier access after checking operational dependencies.
• Verify MFA in the authentication system the store actually uses. Check recovery arrangements so an unavailable device does not lead to an improvised shared login.
• Review login-attempt limits, session expiry and password-reset controls. Test legitimate access after a change, with a recovery route available.
• A non-obvious admin URL can reduce automated noise but cannot replace authentication or patching. Review VPN or IP restrictions with the hosting provider where appropriate.
• Evidence to retain: approved user and role list, MFA verification and the next access-review date. Never put passwords or recovery codes in the checklist.

4. Control secrets and integration credentials

• Use distinct credentials for production and testing, with the minimum permissions required. Confirm who owns each account and where renewal or expiry alerts go.
• Keep secrets out of repositories, public files, analytics events and ordinary support messages. Use an approved secrets store or secure handover channel.
• Document how to rotate each credential at its issuing service and update dependent jobs safely. Removing a value from Magento does not necessarily revoke the original token.
• If exposure is suspected, contain it and coordinate rotation with incident responders. Changing an encryption key alone does not revoke credentials an attacker has already obtained.
• Evidence to retain: credential identifiers, owners, permissions and rotation-test dates, not the secret values themselves.

5. Check hosting exposure and deployment hygiene

• Confirm that database, cache, search and management services are restricted to the clients that need them. Ask the provider for evidence of the network rules rather than guessing from a storefront scan.
• Keep configuration files, repository metadata, database exports, logs and diagnostic utilities outside public access. Remove abandoned development tools through a reviewed change.
• Review file ownership and writable locations against the deployment model. Do not apply blanket permission changes to silence an error.
• Confirm HTTPS and certificate renewal, then review WAF coverage and alerts with the provider. Test rule changes against checkout and integrations; a WAF is an additional control, not a patch substitute.
• Evidence to retain: provider findings, approved configuration changes and the production release reference that implemented them.

6. Inspect checkout scripts and browser protections

• Investigate unfamiliar scripts, destinations or recent content changes. A known tag-manager container is not proof that every tag inside it is approved.
• Review Content Security Policy against the actual Magento version and payment implementation. Adobe documents report-only and restrictive modes; report-only records violations but does not block them.
• Use staging and controlled payment tests when changing CSP. Check browser errors, redirects, payment challenges and order completion; do not solve a broken integration by allowing every script source.
• Evidence to retain: the approved script inventory, change approvals and browser-policy test results. This work supports security but does not by itself certify payment compliance.

7. Prove that backups can restore trading

• Check coverage for the database, media, application code and necessary configuration. Identify dependencies that live outside the hosting account.
• Protect backup access separately and record who can request or perform a restore. Make sure recovery instructions are accessible if the normal admin system is unavailable.
• Restore a representative backup into an isolated environment. Disable real payment processing, outbound customer emails and live integration jobs before testing it.
• Verify sample orders, catalogue data, media and application startup. Record the recovery time, missing dependencies and any manual steps.
• Evidence to retain: backup timestamp, restore-test outcome and a recovery runbook. A green backup job is not a completed restore test, and a backup may contain an older compromise.

8. Make monitoring actionable

• Review application, authentication, deployment and relevant provider logs. Confirm timestamps, retention and access before an incident requires them.
• Investigate unexpected admin or code changes and unusual checkout behaviour. Compare events with authorised releases and business activity before drawing conclusions.
• Run scheduled security checks, but record their scope and limitations. A public scanner cannot inspect server processes, establish every installed patch or rule out database changes.
• Test the alert route with a safe, clearly labelled exercise agreed with the recipient. Record acknowledgement and escalation rather than assuming an email was read.
• Evidence to retain: alert owners, last successful delivery test, reviewed findings and unresolved risks with due dates.

9. Prepare the incident response before you need it

• Keep an accessible contact list for the developer, host, payment provider and relevant security advisers. Agree who can restrict checkout or isolate a workload.
• Preserve logs and relevant system state before destructive cleanup. Record the timeline and keep suspicious artefacts available to the authorised investigation team.
• Determine which systems and data may be affected. Coordinate recovery, secret rotation and any required notifications with the appropriate specialists.
• Verify the original access route is closed, restore from trusted material and monitor for recurrence. Do not declare recovery solely because the storefront loads again.
• Evidence to retain: incident runbook, named decision-maker and the outcome of a tabletop exercise using a realistic checkout or compromise scenario.

Turn the checklist into a recurring maintenance record