Magento’s application layer should never face the raw internet. A WAF (web application firewall) and rate limiting at the edge absorb the hostile traffic - probing, scraping, brute force, card testing - before it costs you application resources. Here is the practical architecture, whether your edge is Fastly, Cloudflare or Nginx.
The Endpoint Risk Map
Not all paths deserve equal trust. The effective approach assigns posture per endpoint class:
| Path class | Posture |
|---|---|
/admin* | IP allowlist if possible; strict rate limits otherwise |
/rest/* (API) | Token-required by design; per-token rate limits; block anonymous where unused |
| Checkout/payment endpoints | Aggressive rate limits + reCAPTCHA (card testing) |
/customer/account/login | Credential-stuffing limits: per-IP and per-account throttles |
| Catalog/content | Generous - this is what the site is for |
Rate Limiting That Works
The patterns that matter:
- Per-IP request limits: e.g. 30/min on login, 10/min on payment endpoints, 100/min on content. Bots need volume; real users need single digits
- Burst + sustained: a real user bursts (page + assets); bots sustain. Rate limit sustained rates, allow bursts
- Per-identifier, not just per-IP: credential stuffing rotates IPs - throttle by account identifier too, and alert on distributed failure patterns
- Fail-closed on money paths: if the rate-limit service errors, payment endpoints should fail safe, not open
On Fastly, edge rate limiting is native config; on Cloudflare, rate-limiting rules; on bare Nginx, limit_req_zone. The mechanism matters less than having it.
WAF Rules for Magento Specifically
Beyond generic OWASP rulesets, Magento-specific signals worth rules:
downloader,setup, leftover install paths - block outright- Probing for known extension vulnerabilities (
/rss, specific vulnerable module paths) - SQLi/XSS patterns in search and filter parameters - catalogsearch is the classic injection surface
- User-agent and header anomalies on the admin path
Bot Management Realities
Good bots (Google, uptime monitors) must pass; bad bots must not; and user-agent strings prove nothing. Practical stance: verify search-engine bots by reverse DNS if you whitelist them, challenge everything suspicious rather than blocking (challenges are reversible, blocks lose customers), and accept that determined scrapers get some data - your goal is raising their cost, not perfection.
The Feedback Loop
WAF and rate-limit configs drift wrong over time: legitimate new integrations get blocked, new attack paths stay open. Review weekly during attacks, monthly in calm: top blocked IPs (false positive check), top blocked paths (attack map), and any legitimate integration caught in the rules.
Edge defence is where hostile traffic should die - cheaply, before it touches PHP. Map your endpoints, rate-limit by their risk, and review the block logs like they are the nightly news from your storefront’s border. They are.