Cloudflare-WAF bei Magento 2: Warum "Protected" nicht gleich sicher heißt

Im Cloudflare-Dashboard steht "Protected". Das Security Level ist auf High. Der Badge für das Managed Ruleset ist grün. Nichts davon bedeutet, was du denkst. Wir prüfen alle paar Wochen Cloudflare-Zonen von Magento-2-Shops, und die Lücke zwischen "im Dashboard sieht's gut aus" und "in der Realität ist es offen" ist so verlässlich, dass wir sie mittlerweile einkalkulieren. Ein geschultes Auge fragt nicht, ob die Regeln existieren. Es fragt, wo sie deaktiviert, umgangen oder mit Allowlist-Einträgen ins Leere laufen.

Der folgende Neun-Punkte-Check ist das, was wir gegen jede Cloudflare-Zone fahren, sobald ein Magento-2-Shop im Scope steht. Er orientiert sich am Cloudflare-Produktportfolio, wie es sich 2026 darstellt. Mit kostenpflichtigen Zusatzprodukten (Enterprise WAF, Advanced Rate Limiting, Custom Rules mit höherem Limit) wird der Check umfangreicher, aber die neun Punkte unten gelten auf jedem Tarif.

TL;DR

• "Cloudflare Managed Ruleset: deployed" ist nicht dasselbe wie "OWASP Core Ruleset: enabled". Bei den meisten Shops, die wir uns ansehen, ist Letzteres abgeschaltet.
• Eine WAF-Bypass-Regel, die auf einem User-Agent-String matcht, kann jeder umgehen, der einen User-Agent setzen kann. Und das kann jedes curl-Kommando im Netz.
• Allowlistete IPs sammeln sich über Jahre an, gelöscht wird da selten was. In älteren Zonen ist ein Großteil der Allowlist-Einträge die private VPN-IP von jemandem, der längst nicht mehr im Team ist.
• Eine Page Rule oder Firewall-Regel, die die WAF auf einem eigenen Admin-Pfad global abschaltet, ohne IP-Eingrenzung, ist faktisch keine WAF auf diesem Pfad.
• Rocket Loader auf einem Magento-2-Storefront reißt fast immer RequireJS-Flows in Produktion, selbst wenn die QA nichts davon merkt.
• TLS min. 1.2+ und HSTS mit includeSubDomains sind PCI-DSS-Pflichtprogramm, kein Nice-to-have.

Check 1: Ist das OWASP Core Ruleset wirklich aktiv?

Das OWASP Core Ruleset ist das, was dich eigentlich schützt. Das Cloudflare Managed Ruleset fängt die groben Angriffe ab, aber SQLi- und XSS-Signaturen stecken im OWASP-Regelwerk. Es ist als eigener Schalter unter Security → WAF → Managed Rules → OWASP Core Ruleset ausgeliefert, und erstaunlich viele Shops haben ihn auf disabled stehen, weil irgendwann mal ein legitimes Formular einen Fehlalarm ausgelöst hat und niemand die Sache je wieder angefasst hat.

Die Konsequenz: Dein Schutz gegen SQL-Injection auf Applikationsebene ist dann die Applikation selbst. Wenn irgendein Vendor-Modul in deiner Magento-Installation eine Raw-Concat-SQL-Query in einem Admin-Controller versteckt, ist genau das OWASP-Ruleset die einzige Instanz zwischen diesem Bug und dem offenen Internet. Es abzuschalten heißt: Gürtel weg, nur noch Hosenträger.

So prüfst du es: Security → WAF → Managed Rules. Die Zeile "OWASP Core Ruleset" muss Enabled zeigen. Steht sie auf disabled oder Log-only, sieh im Changelog nach, warum, und prüfe, ob der Grund heute noch trägt. Die meisten "False-Positive"-Deaktivierungen waren ursprünglich ein kurzer Diagnose-Flip, den einfach niemand zurückgedreht hat.

Check 2: Hebeln Firewall-Regeln die WAF über den User-Agent aus?

Der User-Agent-Header wird vom Client gesetzt. Jeder kann ihn auf jeden beliebigen String stellen. Wenn in deiner Zone eine Firewall-Regel der Form if http.user_agent contains "SomeTrustedScanner" then action: Skip (All) existiert, kann diese jeder auslösen, der einfach mit dem passenden UA-String curlt.

Wir sehen das in zwei Varianten. Die eine: ein altes Monitoring-Tool, dessen UA beim Go-live allowlisted wurde und nie wieder überprüft wurde, als das Tool längst ersetzt war. Die teurere Variante: ein Bypass, der auf den Standard-UA von Cloudflares eigenem Scraping-Bot matcht, wodurch bösartiger Traffic, der sich als Cloudflare selbst ausgibt, ungeprüft durch die WAF spaziert.

So prüfst du es: Security → WAF → Custom Rules. Alle Regel-Expressions durchsuchen, die http.user_agent enthalten. Jeder Treffer braucht eine dokumentierte Begründung im Changelog. Keine Begründung, keine Regel.

Check 3: Kannst du jede allowlistete IP in deiner Zone eindeutig zuordnen?

Cloudflares Security → WAF → Tools → IP Access Rules (und äquivalent: Custom Rules mit einer auf IP gescopten Skip-Action) wachsen über die Jahre. Agenturen, Monitoring-Dienste, Support-Techniker, die private VPN eines Entwicklers. Jeder Eintrag hatte irgendwann einen Grund. Die meisten bleiben, nachdem der Grund längst weg ist.

Der Audit-Schritt ist simpel und unbequem zugleich: jede allowlistete IP in der Zone durchgehen und einem Owner zuordnen. Jede IP ohne klaren, aktuellen Owner fliegt raus. Wir haben Zonen gesehen mit IPs, die vor fünf Jahren für einen Support-Dienstleister freigegeben wurden, der 2020 dichtgemacht hat. Und wir haben Zonen gesehen, in denen eine konkret verdächtige IP-Adresse mit vollem WAF-Skip freigeschaltet war, und die Person, die das eingetragen hatte, war schon lange nicht mehr im Unternehmen.

Besonders achten solltest du auf Einträge, die während eines Incidents hinzugefügt wurden ("dieser Scanner triggert gerade Regeln, lass ihn erstmal durch") und danach nie wieder entfernt wurden. Solche Einträge sind das Schlechteste aus beiden Welten: Wer auch immer während des Incidents angegriffen hat, hat jetzt einen dauerhaften Freifahrtschein durch deine WAF.

Check 4: Admin-Pfad-Bypass ohne IP-Eingrenzung

Ein Muster, das in Cloudflare-Configs immer wieder auftaucht: Ein eigener Admin-Pfad wird allowlisted, damit Admin-Nutzer nicht in WAF-Fehlalarme laufen. Die richtige Form dieser Regel ist path matches /your-admin AND src_ip in known_office_IPs THEN Skip (All). Die falsche Form ist path matches /your-admin THEN Skip (All), ganz ohne IP-Eingrenzung.

Die falsche Form schaltet die WAF auf deinem Admin-Pfad für das gesamte Internet ab. Jeder Credential-Stuffing-Bot, jeder Admin-Token-Fuzzer und jeder Drive-by-SQLi-Scanner, der auf den Admin-Login-Endpoint zielt, kommt ohne WAF-Prüfung durch. Die Regel ist meistens fünf Jahre alt oder älter und stammt aus einer Zeit, bevor IP-Scoping in Cloudflare einfach zu konfigurieren war.

So prüfst du es: Security → WAF → Custom Rules. Jede Regel, deren Pfad-Expression mit uri.path starts_with "/admin" oder Ähnlichem beginnt und eine Skip-Action hat, braucht eine IP-Source-Klausel in derselben Expression. Fehlt die, ist die Regel ein zonenweiter Admin-Bypass.

Check 5: Rocket Loader auf einem Magento-2-Storefront

Rocket Loader verzögert die JavaScript-Ausführung, indem er <script>-Tags so umschreibt, dass sie erst nach dem Rendern asynchron nachladen. Für die meisten Websites funktioniert das gut. Für Magento 2 ist es fast immer kaputt, weil der Storefront auf RequireJS-Module setzt, die synchrones Laden und eine ganz bestimmte Ausführungsreihenfolge erwarten.

Schaltest du Rocket Loader ein, hängt es vom Theme ab, was bricht: Der Minicart aktualisiert sich lautlos nicht mehr, der Warenkorb-Button reagiert beim ersten Klick nicht, Checkout-Schritte hängen sich auf, customer-data.js füllt sich nicht. Die Symptome treten unregelmäßig genug auf, dass QA sie nicht zuverlässig reproduziert; in den Produktionslogs tauchen sie als vereinzelte Fehlermeldungen auf, die niemand auf eine gemeinsame Ursache zurückführt.

So prüfst du es: Speed → Optimization → Rocket Loader. Steht er auf On, schalte ihn aus und beobachte, ob sich eine Frontend-Metrik bewegt. Steht er auf Off, stelle sicher, dass keine Page Rule ihn für einzelne Pfade wieder anschaltet. Ein Fünf-Sekunden-Fix, den trotzdem jemand tatsächlich machen muss.

Check 6: TLS-Mindestversion und HSTS

Zwei Einstellungen, beide unter SSL/TLS → Edge Certificates.

Minimum TLS Version muss auf 1.2 oder höher stehen. TLS 1.0 und 1.1 haben bekannte Schwachstellen (POODLE, BEAST) und sind nicht PCI-DSS-4.0-konform. Ein Shop, der Zahlungen auf einer Zone mit Min TLS 1.0 abwickelt, hat spätestens beim nächsten PCI-Audit ein Compliance-Problem. Auf 1.2 zu gehen ist meist ein einziger Klick; 1.3 als Minimum ist konservativ und für die meisten Storefronts völlig in Ordnung, aber für Shops mit viel Legacy-Client-Traffic eher aggressiv.

HSTS (HTTP Strict Transport Security) weist Browser an, für die Zone gar keine HTTP-Verbindungen mehr zuzulassen. Ist es deaktiviert oder auf max_age=0 gesetzt, kann ein Angreifer im offenen Flughafen-WLAN einem Kunden, der die nackte Domain eintippt, weiterhin eine HTTP-Seite unterschieben. Aktiviere HSTS mit max_age: 31536000, includeSubDomains: true, und zieh preload: true nach dem Testen in Betracht. Bei einem E-Commerce-Shop mit Zahlungsdaten ist deaktiviertes HSTS eine echte Angriffsfläche.

Check 7: Was macht der Edge mit Marketing- und Filter-Parametern?

Über Cloudflares Cache-Rules-Seite kannst du Query-Parameter entfernen, bevor die Anfrage überhaupt bei deinem Origin ankommt. Konfigurierst du das nicht, sieht dein Varnish jeden gclid, utm_*, fbclid, srsltid, _gl als cache-key-relevanten Parameter, und jeder Ad-Klick landet als kalter MISS. Das ist eher ein Performance-Problem als ein Security-Problem, aber der einzige Punkt auf dieser Liste, der beides zugleich ist.

Zur Security-Implikation am Edge: Cache-Regeln, die Parameter vor dem Origin abschneiden, beeinflussen auch, was Magento überhaupt in $_GET zu sehen bekommt. utm_* am Edge zu strippen ist unkritisch, das interessiert Magento nicht. Einen Form-Key- oder CSRF-Token-Parameter am Edge zu strippen bricht Magento dagegen sofort. Wir haben schon zu weit gefasste Strip-Regeln gesehen, die versehentlich Parameter gelöscht haben, auf die der Storefront angewiesen war, weil jemand "alle Tracking-Parameter strippen" mit einer viel zu aggressiven Regex umgesetzt hatte.

So prüfst du es: Caching → Cache Rules. Liste jede Regel auf, die die Request-URL oder den Query-String verändert. Bestätige, dass die Parameterliste explizit, konservativ und dokumentiert ist.

Check 8: Page Rules, die Sicherheit auf admin-ähnlichen Pfaden global abschalten

Page Rules (das Legacy-Produkt) und Configuration Rules (der neuere Nachfolger) können jede Zoneneinstellung pro URL-Muster überschreiben. Das ist legitim und nützlich, aber genau dort werden aus "WAF für den Incident kurz abschalten"-Entscheidungen dauerhafte Zustände.

Das konkrete Anti-Pattern, nach dem du suchen solltest: eine Page Rule mit einem Muster wie /etwas-admin-artiges/*, die Security Level, Browser Integrity Check oder Bot Fight Mode für diesen Pfad global deaktiviert. Die ursprüngliche Absicht war meistens, Admin-Traffic keine Challenges zu präsentieren. Der Effekt entspricht Check 4: Du hast die Perimeter-Security für den Admin-Pfad für das komplette Internet abgeschaltet.

So prüfst du es: Rules → Configuration Rules (und Rules → Page Rules bei Legacy-Zonen). Lies jede Regel durch. Jede Regel, die ein Security-Feature auf einem admin-nahen Pfad deaktiviert, braucht eine IP-Eingrenzung in der Match-Klausel. Fehlt sie, jetzt korrigieren.

Check 9: Rate Limiting auf dem Admin-Token-Endpoint

Magentos REST-API stellt /rest/V1/integration/admin/token für den programmatischen Admin-Login bereit. Genau diesen Endpoint trifft ein Credential-Stuffing-Bot, sobald er erkennt, dass er es mit einem Magento-Shop zu tun hat. Cloudflare bietet Rate Limiting als eigenes Produkt an (im Free-Tier eingeschränkt, in den bezahlten Tiers großzügiger). Die meisten Zonen, die wir prüfen, haben überhaupt kein Rate Limit auf /rest/V1/*.

Ein minimal-taugliches Rate Limit: 10 Requests pro Minute pro IP auf POST /rest/V1/integration/admin/token, Action: Block. Großzügigere Schwellenwerte sind für Shops mit legitimen Integrationspartnern angebracht, aber der Schwellenwert sollte immer auf den Endpoint gescopt sein, nicht zonenweit gelten.

So prüfst du es: Security → WAF → Rate Limiting Rules. Ist die Liste leer, hast du kein Rate Limiting. Ergänze die Regel oben als ersten Schritt. Gibt es schon Regeln, lies jede einzelne durch und verifiziere, dass Schwellenwert und Scope wirklich zum Admin-Token-Traffic passen.

Weiterführende Artikel

• Dangling CNAMEs and Subdomain Takeover: The DNS Ghosts Haunting Old Magento Stores. HSTS mit includeSubDomains greift spürbar in deine DNS-Zone ein. Räum die DNS-Seite auf, bevor du HSTS scharf schaltest.

Die Neun-Punkte-Cloudflare-Checkliste

1. OWASP Core Ruleset auf Enabled bestätigen

   Security → WAF → Managed Rules. OWASP Core Ruleset muss Enabled sein (nicht Log-only, nicht Disabled). Jeder Disabled-Status braucht eine aktuelle Begründung und ein Datum für die Wiederaktivierung; veraltete "temporäre" Deaktivierungen reaktivieren und die Fehlalarme triagieren.

2. Jede UA-basierte WAF-Bypass-Regel entfernen

   Security → WAF → Custom Rules. Die Regel-Expressions nach http.user_agent durchsuchen. Jeder Treffer ist ein Bypass, den jeder Client durch Setzen des Headers auslösen kann. Durch IP-gescopte Regeln ersetzen oder löschen.

3. Jede allowlistete IP neu rechtfertigen

   Security → WAF → Tools → IP Access Rules plus Custom Rules mit Skip-Action. Jedem Eintrag einen Owner zuordnen. Jeden Eintrag ohne aktuellen Owner entfernen. Besonders Einträge prüfen, die während eines Incidents hinzukamen und nie wieder entfernt wurden.

4. Admin-Pfad-Bypässe auf Office-IPs eingrenzen

   Jede Custom Rule, die einen Admin-Pfad (/admin, /your-admin, /adminhtml) mit Skip-Action matcht, braucht eine src_ip-Klausel. Zonenweite Admin-Bypässe sind gleichbedeutend mit gar keiner WAF auf dem Admin-Pfad.

5. Rocket Loader für Magento-Storefronts ausschalten

   Speed → Optimization → Rocket Loader = Off. Sicherstellen, dass keine Page Rule oder Configuration Rule ihn für irgendeinen Pfad wieder auf On stellt. Nach der Änderung Minicart, Warenkorb-Button und Checkout-Schritte erneut testen.

6. TLS-Minimum auf 1.2 setzen und HSTS sauber aktivieren

   SSL/TLS → Edge Certificates. Minimum TLS Version = 1.2 (oder 1.3). HSTS aktiv mit max_age 31536000, includeSubDomains true. Vor dem Umlegen von includeSubDomains alle Subdomains auf TLS-Abdeckung prüfen.

7. Query-String-Manipulation am Edge prüfen

   Caching → Cache Rules. Jede Regel auflisten, die Query-Parameter entfernt oder umschreibt. Bestätigen, dass die Parameterliste explizit, dokumentiert ist und nicht versehentlich Form-Key- oder CSRF-Token-Parameter strippt.

8. Globale Security-Overrides auf Admin-Pfaden in Page Rules abschalten

   Rules → Page Rules und Configuration Rules. Jede Regel, die Security Level, Browser Integrity Check oder Bot Fight Mode auf einem admin-ähnlichen Pfad deaktiviert, braucht eine IP-Eingrenzung oder gehört gelöscht.

9. Admin-Token-Endpoint mit Rate Limit versehen

   Security → WAF → Rate Limiting Rules. Mindestens: 10 Requests/Minute pro IP auf POST /rest/V1/integration/admin/token, Action Block. Andere /rest/V1/*-Endpoints auf ähnliche Schwellenwert-Regeln prüfen.