Application security is a few concrete controls: the HTTP session, the admin panel, secrets, libraries, file upload and a scan of known gaps. A firewall at the edge cuts the mass. It does not patch Magento or a plugin.
The goal is simple: make session theft, panel entry and a database password leak from the repo harder.
What to turn on
A session cookie with HttpOnly, Secure and SameSite limits theft of the identifier through a script on the page and sending it over plain HTTP. Two-factor login on the panel cuts a password leaked from phishing. A secret in a manager or in deploy variables, not in Git: a public repo scan does not get the database.
composer audit and npm audit show known gaps in libraries. An agent on the host alerts when someone changes store configuration or adds a file in the media directory. A vulnerability scan finds old PHP and open ports. Masking a dump on staging cuts a copy of production on an agency laptop.
How to set it in practice
In Magento: cookies only over HTTPS, 2FA on every admin account, your own panel path, env.php outside the repo, no PHP execution under media. In CI the job fails on a critical Composer gap.
In WordPress: turn off file editing from the panel, 2FA or SSO, xmlrpc off if unused, plugins with an update date.
On the host: a Wazuh agent on configuration and nginx, a weekly scan of origin and the panel, the admin panel behind Cloudflare Access or a VPN, not a password alone on public 443.
Layers: security.
In short: the edge cuts the mass. The application is protected by the session, 2FA, secrets outside Git and current dependencies. Without that the panel and the database stay in range of the first scan.