Magento Monitoring — What Exactly We Check

A Magento store can return a 200 status and look perfectly normal while sending customers' card details to someone else's server. That is why, for Magento 1 and 2, MonitorWWW.com does more than an availability test: it recognises the platform automatically and checks what most often breaks and gets attacked in these stores.

Card skimmers and the cart page

• Suspicious code in the cart — we look for patterns typical of skimmers (Magecart): scripts activated only on the payment page, execution of encoded code, reading card fields combined with sending data out, WebSocket connections to foreign domains and scripts disguised as images.
• External script domains — we remember the list of domains the cart loads JavaScript from and raise an alert when a new one appears.
• Cart and login availability — whether /checkout/cart/ and /customer/account/login/ respond and do not show a Magento error page.

The scan covers the HTML of the cart page. It is heuristic detection: it catches typical injections but does not replace a file and database audit after a breach.

Installation security

• Configuration files — publicly accessible app/etc/env.php (Magento 2) or app/etc/local.xml (Magento 1).
• Database dumps — dump.sql and backup.sql in the web root.
• Installer and Magento Connect — reachable /setup/ and /downloader/.
• Logs — downloadable var/log/system.log and exception.log.
• Directory listing — var/backups, var/report, var/export and media.
• phpinfo — leftover phpinfo.php / info.php files.
• composer.json — a public file gives away the exact version and module list.
• Document root — whether the server points at the /pub directory or at the Magento root.
• Admin panel — whether it runs at the default /admin address.
• REST and GraphQL — product catalog access without a token and open schema introspection.

Version and end of support

• Version and edition — read from /magento_version or composer.json when the store exposes them.
• End of support — a warning for Magento 1 and the 2.0–2.3 branches, which no longer receive security fixes.
• Newer release — when we know the exact version, we compare it with the latest Magento Open Source release.

How often, and why not all at once

We check store availability every few minutes. Security probes are spread across the whole day: 22 requests a day, at most two at a time, roughly every 100 minutes and at irregular intervals. A burst of requests for unusual files within one second looks like a scan to a WAF and ends with the IP address being blocked. On a newly added site the first full cycle runs faster, in about four hours.

Everything is checked from the outside — no module in the store, no access to the admin panel or the server.

Alerts

Besides the outage alert, we send a separate security alert (email, Telegram, webhook) when we detect suspicious code in the cart, a new script domain, a public configuration file or a database dump. Other findings are in the dashboard together with a fix.

What we check on every site, regardless of platform

• Uptime and response time — HTTP status, load time, redirects, maintenance mode.
• SSL certificate and domain — certificate validity and domain expiry date, with an alert ahead of time.
• DNS — SPF, DMARC, MX and CAA records.
• Security headers — HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and cookie flags.
• Files that should not be visible — .env, .git, phpMyAdmin, backups, directory listing.
• Malware and PHP errors — suspicious code and error messages in the page content.
• Blacklists — whether the domain has been flagged as unsafe.
• Content changes — an optional keyword that must be present on the page.