Deine Cloudflare-WAF gibt dir vermutlich falsche Sicherheit: ein Neun-Punkte-Audit

Dein Cloudflare-Dashboard sagt „Protected". Das Security Level steht auf High. Das Managed-Ruleset-Badge ist grün. Nichts davon bedeutet, was du denkst. Wir fahren alle paar Wochen Cloudflare-Audits auf Magento-2-Shops, und die Dashboard-sagt-ja-Realität-sagt-nein-Lücke ist konstant genug, um ein Topos zu sein. Was ein geschultes Auge sucht, ist nicht, ob die Regeln existieren. Es ist, wo sie deaktiviert, bypasst oder in die Nutzlosigkeit allowlisted wurden.

Unten steht der Neun-Punkte-Audit, den wir gegen eine Cloudflare-Zone fahren, wenn ein Magento-2-Shop im Scope ist. Er orientiert sich an der Cloudflare-Produktlinie, wie sie 2026 steht. Mit bezahlten Add-ons (Enterprise WAF, Advanced Rate Limiting, Custom Rules mit höherem Limit) werden die Checks reichhaltiger, aber die neun unten gelten auf jedem Tier.

Das OWASP Core Ruleset ist das, was du eigentlich willst. Das Cloudflare Managed Ruleset fängt breite Angriffe ab, aber SQLi- und XSS-Signaturen leben im OWASP. Es ist als separater Toggle unter Security → WAF → Managed Rules → OWASP Core Ruleset ausgeliefert, und auf erstaunlich vielen Shops steht es auf disabled, weil jemand einmal Fehlalarme bei einem legitimen Formular hatte und nie zurückgekommen ist.

Die Konsequenz: Dein Application-Layer-Schutz gegen SQL-Injection ist die Applikation selbst. Wenn deine Magento-Installation ein Vendor-Modul mit einer Raw-Concat-SQL-Statement in einem Admin-Controller hat (siehe Die 7 Security-Findings, die wir in fast jedem Magento-2-Code-Audit sehen, Finding #3), ist das OWASP-Ruleset das, was zwischen diesem Bug und dem Internet steht. Es abzuschalten nimmt den Gürtel weg und lässt nur die Hosenträger stehen.

So prüfst du: Security → WAF → Managed Rules. Die Zeile „OWASP Core Ruleset" muss Enabled sagen. Wenn sie auf disabled oder Log-only steht, den Grund im Changelog lesen und bestätigen, dass der Grund noch gilt. Die meisten „False-Positive"-Deaktivierungen waren temporäre Diagnose-Flips, die niemand zurückgedreht hat.

Ein User-Agent-Header wird vom Client kontrolliert. Jeder kann ihn auf jeden String setzen. Wenn deine Zone eine Firewall-Regel der Form if http.user_agent contains "SomeTrustedScanner" then action: Skip (All) hat, ist diese Regel ein Bypass, den jeder durch curlen mit dem passenden UA-String auslösen kann.

Wir haben das in zwei Varianten gesehen. Mal ist es ein Legacy-Monitoring-Tool, dessen UA beim Go-Live allowlisted wurde, und nie nachgepflegt, als das Tool ersetzt wurde. Die teurere Variante ist ein Bypass auf den Default-Cloudflare-Scraping-Bot-UA der Zone, was bedeutet, dass bösartiger Traffic, der sich als Cloudflare selbst ausgibt, durch die WAF whitelistet wird.

So prüfst du: Security → WAF → Custom Rules. Die Regel-Expressions nach http.user_agent sortieren. Jeder Treffer braucht eine Begründung im Changelog. Keine Begründung, keine Regel.

Cloudflares Security → WAF → Tools → IP Access Rules (und äquivalent Custom-Rules mit einer Skip-Action auf IP) wachsen mit der Zeit. Contractors, Monitoring-Services, Support-Engineers, Heim-VPNs von Entwicklern. Jeder wurde aus einem Grund ergänzt. Die meisten blieben, nachdem der Grund weggefallen war.

Der Audit-Schritt ist schlicht und unbequem: jede allowlistete IP der Zone durchgehen und ihr einen Owner zuordnen. Jede IP ohne klaren aktuellen Owner fliegt raus. Wir haben Zonen gefunden mit IPs, die vor fünf Jahren für einen Support-Vendor allowlisted wurden, der 2020 pleiteging. Wir haben auch Zonen gefunden, in denen eine konkrete verdächtige IP explizit mit vollem WAF-Skip allowlistet war, und die Person, die das eingetragen hatte, nicht mehr im Unternehmen war.

Der konkrete Fall, auf den du achten solltest: ein Allowlist-Eintrag, der während eines Vorfalls hinzugefügt wurde („dieser Scanner löst Regeln aus, lass ihn erstmal durch") und nie entfernt. Solche Einträge sind das Schlechteste aus beiden Welten; wer auch immer während des Vorfalls angegriffen hat, hat jetzt einen dauerhaften Freifahrtschein durch deine WAF.

Ein verbreitetes Muster in Cloudflare-Configs: ein Custom-Admin-Pfad (welcher bei dir auch immer) wird allowlistet, 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) ohne IP-Scope.

Die falsche Form schaltet die WAF auf deinem Admin-Pfad für das gesamte Internet aus. Jeder Credential-Stuffing-Bot, jeder Admin-Token-Fuzzer und jeder Drive-by-SQLi-Scanner, der den Admin-Login-Endpoint trifft, segelt ohne WAF-Inspektion durch. Die Regel ist meistens fünf Jahre alt und älter als die heute einfach nutzbare IP-Scope-Funktion.

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

Rocket Loader verschiebt JavaScript-Ausführung, indem er <script>-Tags so umschreibt, dass sie asynchron nach dem Page-Render laden. Auf den meisten Sites funktioniert das. Auf Magento 2 ist es fast immer kaputt, weil Magentos Storefront auf RequireJS-Module setzt, die synchrones Script-Loading in einer konkreten Reihenfolge erwarten.

Rocket Loader einschalten, und was bricht, hängt vom Theme ab: Minicart-Refresh scheitert still, der „In den Warenkorb"-Button macht beim ersten Klick nichts, Checkout-Schritt-Übergänge hängen, customer-data.js füllt sich nicht. Die Symptome sind sporadisch genug, dass QA sie nicht zuverlässig reproduziert; sie tauchen in Produktionslogs als vereinzelte Fehler-Reports auf, die niemand an eine Einzelursache zurückknüpft.

So prüfst du: Speed → Optimization → Rocket Loader. Wenn On, ausschalten und beobachten, ob sich irgendeine Frontend-Metrik bewegt. Wenn Off, sicherstellen, dass keine Page-Rule ihn für bestimmte Pfade wieder auf On zwingt. Fünf-Sekunden-Fix, aber jemand muss es tatsächlich tun.

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

Minimum TLS Version muss 1.2 oder höher sein. 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 annimmt, ist ein Compliance-Problem in dem Moment, in dem ein PCI-Auditor hinschaut. Auf 1.2 zu gehen ist meist ein Klick; auf 1.3 als Min zu gehen ist konservativ und für die meisten Storefronts in Ordnung, aggressiv für solche mit viel Legacy-Client-Traffic.

HSTS (HTTP Strict Transport Security) sagt Browsern, HTTP-Verbindungen für die Zone abzulehnen. Wenn disabled oder max_age=0, kann ein MITM-Angreifer im Flughafen-WLAN weiterhin HTTP-Seiten an einen Kunden ausliefern, der die nackte Domain getippt hat. HSTS mit max_age: 31536000, includeSubDomains: true aktivieren und preload: true nach Testen in Betracht ziehen. Für einen E-Commerce-Shop mit Zahlungsdaten ist HSTS deaktiviert eine reale Lücke.

Cloudflares Cache-Rules-Seite erlaubt, Query-Parameter zu entfernen, bevor die Anfrage deinen Origin erreicht. Ohne Konfiguration sieht dein Varnish jeden gclid, utm_*, fbclid, srsltid, _gl als cache-key-relevant, und jeder Ad-Klick wird ein kalter MISS. Das ist ein Performance-Problem, nicht streng ein Security-Problem, aber der eine Punkt auf dieser Liste, der auch ein Varnish-Problem ist.

Zur Edge-Layer-Security-Implikation: Cache-Regeln, die Parameter strippen, bevor sie den Origin erreichen, beeinflussen auch, was Magento in $_GET sieht. utm_* am Edge zu strippen ist in Ordnung (Magento schert sich nicht darum). Ein Form-Key- oder CSRF-Token-Parameter am Edge zu strippen bricht Magento. Wir haben zu weit gefasste Strip-Regeln gesehen, die Parameter versehentlich löschen, auf die der Storefront angewiesen war, weil jemand „strip all tracking parameters" mit einer Regex konfiguriert hat, die zu aggressiv gematcht hat.

So prüfst du: Caching → Cache Rules. Jede Regel auflisten, die die Request-URL oder den Query-String modifiziert. Bestätigen, dass die Parameterliste explizit, konservativ und dokumentiert ist.

Page Rules (das Legacy-Produkt) und Configuration Rules (der neuere Ersatz) können jede Zonen-Einstellung pro URL-Pattern überschreiben. Legitim und nützlich; auch der Ort, an dem „WAF auf einem Pfad für einen Vorfall abschalten"-Entscheidungen sich verewigen.

Das spezifische Anti-Pattern: eine Page-Rule mit einem /etwas-admin-artiges/*-Pattern, die Security Level, Browser Integrity Check oder Bot Fight Mode für diesen Pfad global deaktiviert. Die ursprüngliche Intention war meist, Admin-Traffic vor Challenges zu schützen. Die Wirkung ist identisch mit Check 4: du hast die Perimeter-Security für den Admin-Pfad für das gesamte Internet abgeschaltet.

So prüfst du: Rules → Configuration Rules (und Rules → Page Rules für Legacy-Zonen). Jede Regel lesen. Jede Regel, die ein Sicherheits-Feature auf einem admin-nahen Pfad deaktiviert, braucht einen IP-Scope in der Match-Klausel. Fehlt er, jetzt fixen.

Magentos REST-API exponiert /rest/V1/integration/admin/token für programmatischen Admin-Login. Das ist der Endpoint, den ein Credential-Stuffing-Bot trifft, wenn er weiß, dass ein Magento-Shop das Ziel ist. Cloudflare liefert Rate Limiting als separates Produkt (Free-Tier begrenzt, Paid-Tiers großzügig). Die meisten Zonen, die wir auditieren, haben gar kein Rate-Limit auf /rest/V1/*.

Ein minimal-tragfähiges Rate-Limit: 10 Requests pro Minute pro IP auf POST /rest/V1/integration/admin/token, Action: Block. Großzügigere Schwellen funktionieren für Shops mit legitimen Integrationspartnern, aber die Schwelle sollte immer auf den Endpoint gescoped werden, nicht zonenweit angewendet.

So prüfst du: Security → WAF → Rate Limiting Rules. Ist die Liste leer, gibt es kein Rate-Limiting. Die Regel oben als ersten Wurf ergänzen. Gibt es Regeln, jede lesen und verifizieren, dass Schwelle und Scope speziell zum Admin-Token-Traffic passen.

1. 01

   OWASP Core Ruleset als 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 Entfernungsdatum; veraltete „temporäre" Deaktivierungen wieder aktivieren und die Fehlalarme triagieren.

2. 02

   Jede UA-basierte WAF-Bypass-Regel entfernen

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

3. 03

   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. Besondere Aufmerksamkeit auf Einträge, die während eines Vorfalls hinzugefügt und nie entfernt wurden.

4. 04

   Admin-Pfad-Bypässe auf Office-IPs einschränken

   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 dasselbe wie keine WAF auf dem Admin-Pfad.

5. 05

   Rocket Loader für Magento-Storefronts ausschalten

   Speed → Optimization → Rocket Loader = Off. Bestätigen, dass keine Page-Rule oder Config-Rule ihn für irgendeinen Pfad auf On überschreibt. Nach der Änderung Minicart, Add-to-Cart und Checkout-Schritt-Übergänge neu testen.

6. 06

   TLS-Min auf 1.2 setzen und HSTS sauber aktivieren

   SSL/TLS → Edge Certificates. Minimum TLS Version = 1.2 (oder 1.3). HSTS aktiviert mit max_age 31536000, includeSubDomains true. Vor dem Umlegen von includeSubDomains die Subdomains auf TLS-Abdeckung aufzählen.

7. 07

   Edge-Query-String-Manipulation auditieren

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

8. 08

   Globale Admin-Pfad-Security-Overrides 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 einen IP-Scope oder muss gelöscht werden.

9. 09

   Rate-Limit auf dem Admin-Token-Endpoint

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