Magento 2 security essentials for a self-hosted store

Self-hosting Magento 2 means security is your job, not a SaaS vendor's. This post covers the essentials that actually reduce risk — none of them exotic.

Isolate the admin

The /admin path is the highest-value target. Put it behind an access proxy (for example Cloudflare Access) so it's not reachable without an identity, and consider a non-default admin URL. Admin APIs should never be public to anonymous traffic. The same access-control pattern pairs well with a framework-aware local stack — for instance, Govard can keep the admin off your everyday dev domain entirely.

Enforce 2FA

Magento ships TOTP-based 2FA for admin users. Turn it on and require it for every admin account — including service accounts where feasible.

Keep patches current

Security releases land regularly. Track the version, subscribe to advisories, and budget upgrade time rather than scrambling after a CVE. (The safe upgrade pipeline from the earlier Magento 2 in practice series applies here.)

Correct file permissions

Serve from pub/ so app/, etc/, and var/ are not web-reachable. Set ownership/permissions per the official guidance; writable paths should be minimal.

Minimize the attack surface

• Remove unused admin accounts and modules.
• Disable or remove demo/test data and default CMS pages you don't use.
• Restrict app/etc/env.php access — it holds DB and cache credentials.
• Audit third-party extensions; each is code running with your privileges.

Monitor

• Watch exception.log and access logs for scanning patterns.
• Alert on unexpected admin logins and config changes.
• Keep offsite, tested backups.

What's next in this series

Security and performance are easier to hold with tests. Next: a pragmatic Magento 2 testing strategy — unit, integration, and MFTF — that runs locally without being brittle.

Next in this series: Magento 2 testing strategy — /blog/magento2-testing