Cloudflare für Shopware
Shopware 6 ist ein dynamisches System: Warenkorb, Sitzung, Kundengruppen, Preise, Verfügbarkeiten — vieles ändert sich von Besucher zu Besucher. Cloudflare ist für statische Websites voreingestellt. Wer beides einfach zusammensteckt, bekommt fremde Warenkörbe aus dem Cache, Zahlungen, die nicht bestätigt werden, und einen Admin, der nicht mehr speichert. Wir betreiben Shopware-Shops seit Jahren und richten Cloudflare dafür so ein, dass es schützt und beschleunigt, ohne dem Shop im Weg zu stehen.
Die Fehler sind immer dieselben — und sie fallen erst auf, wenn ein Kunde sich meldet.
Eine Cache-Regel, die „alles“ zwischenspeichert, liefert personalisierte Seiten an den nächsten Besucher aus: Warenkorb, Kundenkonto, kundenindividuelle Preise. In einem B2B-Shop ist das ein Datenschutzvorfall, kein Schönheitsfehler.
Der Zahlungsanbieter meldet den Zahlungseingang per Rückruf an den Shop. Der Bot-Schutz sieht eine Maschine ohne Browser und blockiert. Die Bestellung steht auf „offen“, der Kunde hat bezahlt, niemand weiß warum.
Warenwirtschaft, PIM, Preislisten, Marktplatz-Anbindungen: alles Maschinen, die regelmäßig an die API des Shops gehen. Jede davon kann vom Bot Fight Mode oder einer zu breiten Firewall-Regel getroffen werden.
Die Adresse des Shop-Servers ist weiterhin öffentlich bekannt. Wer sie kennt, geht an Cloudflare vorbei — und die gesamte Firewall ist Dekoration.
Eine Unternehmenswebsite liefert jedem Besucher dieselbe Seite. Shopware nicht: Sobald ein Besucher etwas in den Warenkorb legt, sich anmeldet oder eine Kundengruppe mit eigenen Preisen hat, ist die Seite für ihn persönlich. Shopware kennzeichnet das über Cookies und arbeitet mit einem eigenen HTTP-Cache, der genau diese Unterscheidung beherrscht. Cloudflare muss sie übernehmen, nicht übergehen.
Dazu kommen die Maschinen: die Verwaltungsoberfläche mit ihrer API, die Store-API für Headless-Frontends und Apps, die Rückrufe der Zahlungsanbieter, die Synchronisation mit Warenwirtschaft und PIM. Keine davon hat einen Browser, alle sind für einen pauschalen Bot-Schutz verdächtig. Ein Cloudflare-Setup für Shopware ist deshalb vor allem eine Liste von Ausnahmen, die zum Shop passen — und erst dann ein Regelwerk gegen Angreifer.
Statische Dateien — Theme, Skripte, Medien, Produktbilder — darf Cloudflare lange vorhalten. Hier liegt der größte Gewinn für Ladezeit und Serverlast, gerade in Aktionszeiten. Seiteninhalte werden nur dann am Rand zwischengespeichert, wenn der Besucher noch keine Sitzung hat; sobald Shopware einen Sitzungs-Cookie setzt, geht die Anfrage am Cache vorbei zum Shop. Warenkorb, Kasse, Kundenkonto und Verwaltung werden grundsätzlich nie zwischengespeichert.
Shopwares eigener HTTP-Cache bleibt dabei aktiv — beide Schichten müssen zusammenpassen, sonst zeigen sie unterschiedliche Stände. Und das Leeren binden wir an den Shop an: Wird ein Produkt geändert oder ein Preis aktualisiert, verschwindet die alte Fassung auch am Rand, nicht erst nach Ablauf. Komfortfunktionen, die Skripte umschreiben oder nachladen, schalten wir ab; sie brechen Storefront und Verwaltung stillschweigend.
Die Verwaltung erreichen nur die, die sie brauchen: nach Netz, Land oder mit einer Prüfung davor. Die API bleibt für die Schnittstellen offen, die Sie tatsächlich nutzen, und für sonst niemanden. Die Rückruf-Adressen Ihrer Zahlungsanbieter stehen ausdrücklich auf der Erlaubt-Liste, genauso Monitoring und Warenwirtschaft. Anfragen nach Dateien, die es in einem Shopware-Shop nicht gibt — fremde Admin-Pfade, Konfigurations-Backups — werden direkt verworfen.
Beim Bot-Schutz entscheidet der Tarif: Der einfache Bot Fight Mode kennt keine Ausnahmen und ist für einen Shop mit Zahlungsanbieter praktisch nicht nutzbar. Der Super Bot Fight Mode erlaubt verifizierte Bots und eigene Regeln, die bestimmte Pfade ausnehmen — damit sieht der Scanner die Prüfseite und der Zahlungsanbieter nicht. Rate Limiting begrenzt Login-Versuche, Suchanfragen und das Anlegen von Kundenkonten je Absender; Turnstile schützt Registrierung und Kontaktformular ohne Bilderrätsel.
Regeln sind nie fertig. Nach dem Scharfschalten lesen wir die Sicherheitsereignisse und prüfen, ob etwas blockiert wurde, das durch hätte sollen. Fehlalarme werden zu Ausnahmen, neue Muster zu Regeln.
Die Verbindung zwischen Cloudflare und Ihrem Server bleibt durchgehend verschlüsselt — mit einem gültigen Zertifikat auf dem Server, nicht im „flexiblen“ Modus, der den Verkehr hinter Cloudflare im Klartext laufen lässt. Der Server selbst nimmt Web-Anfragen nur noch aus den Netzen von Cloudflare an; auf Wunsch weist sich Cloudflare ihm gegenüber zusätzlich per Zertifikat aus.
Und damit Shopware weiterhin echte Besucher sieht: Protokolle, die eigene Login-Bremse und die Statistik bekommen die ursprüngliche Besucheradresse aus dem Cloudflare-Header statt der Adresse des Cloudflare-Netzes. Ohne dieses Detail läuft jede serverseitige Drosselung ins Leere — und jeder Besucher sieht für den Shop gleich aus.
Das Cloudflare-Konto gehört Ihnen; wir arbeiten als Mitglied mit den nötigen Rechten. Jede Einstellung ist dokumentiert und begründet. Weil sich Angriffsmuster, Ihre Schnittstellen und Cloudflares Funktionen ändern, gehört die Zone in den regelmäßigen Prüfzyklus unserer Shopware-Wartung.
Zur Einordnung: Cloudflare ist ein US-Anbieter, über dessen Netz der Verkehr Ihrer Kunden läuft. Der Einsatz gehört in die Datenschutzerklärung des Shops und braucht einen Auftragsverarbeitungsvertrag, den Cloudflare bereitstellt. Die technischen Angaben dafür liefern wir.
Ablauf
Schicken Sie uns die Shop-Domain und, wenn vorhanden, eine Liste Ihrer Schnittstellen und Zahlungsanbieter. Sie bekommen eine Einschätzung, was in Ihrer Lage sinnvoll ist — vor dem ersten Klick in Cloudflare.
Welche Schnittstellen, Zahlungsanbieter und Apps greifen auf den Shop zu? Welche Pfade, welche Absender? Was ist in einer bestehenden Zone bereits eingestellt?
DNS, durchgehende Verschlüsselung, Server nur für Cloudflare erreichbar, echte Besucheradressen im Shop.
Regeln für statische Dateien und Seiten, Umgehung bei Sitzung, Zusammenspiel mit dem Shopware-Cache, Leerung bei Änderungen.
Erlaubt-Liste für Zahlungsanbieter und Schnittstellen, Schutz für Verwaltung und API, Bot Fight Mode passend zum Tarif, Rate Limiting, Turnstile.
Testbestellung über jeden Zahlungsweg, Schnittstellen-Durchlauf, dann Sicherheitsereignisse lesen und Regeln nachführen.
Projekte auf diesem System
Ein Auszug — nicht die vollständige Kundenliste.
Für statische Dateien deutlich: Bilder, Skripte und Styles kommen vom Cloudflare-Rand in der Nähe des Besuchers statt von Ihrem Server. Bei den Seiten selbst hängt es davon ab, wie viele Besucher ohne Sitzung unterwegs sind — Produkt- und Kategorieseiten für anonyme Besucher lassen sich zwischenspeichern, personalisierte Seiten nicht. Was Cloudflare nicht ersetzt, ist ein schneller Shop dahinter: Ein langsamer Checkout bleibt langsam.
In der Praxis mindestens der Pro-Tarif. Der Grund ist der Bot-Schutz: Im kostenlosen Tarif gibt es nur den einfachen Bot Fight Mode ohne Ausnahmen — er trifft Zahlungsanbieter und Schnittstellen genauso wie Scanner. Erst der Super Bot Fight Mode erlaubt verifizierte Bots und eigene Ausnahmen. Dazu kommen die vollständigen verwalteten Firewall-Regelsätze. Die genauen Grenzen je Tarif ändert Cloudflare gelegentlich; wir prüfen sie bei der Einrichtung.
Fast immer der Bot-Schutz oder eine Firewall-Regel: Die Rückmeldung des Zahlungsanbieters kommt von einem Server ohne Browser und wird als Automat behandelt. Die Bestellung bleibt auf „offen“, obwohl bezahlt wurde. Die Lösung ist eine Erlaubt-Liste für die Rückruf-Adressen des Anbieters und ein Bot-Schutz, der Ausnahmen kennt — und ein Testlauf über jeden Zahlungsweg, bevor der Shop wieder frei ist.
Ja, wenn Komfortfunktionen aktiv sind, die JavaScript umschreiben oder nachladen, oder wenn Verwaltungspfade zwischengespeichert werden. Symptom: Die Verwaltung lädt nicht, speichert nicht oder zeigt alte Stände. Wir schalten diese Funktionen ab, nehmen Verwaltung und API vom Cache aus und schützen sie stattdessen über die Firewall.
Er bleibt aktiv und ist die erste Schicht; Cloudflare ist die zweite. Beide müssen dieselbe Logik haben: Wann ist eine Seite für alle gleich, wann persönlich? Und beide müssen beim Veröffentlichen geleert werden, sonst zeigt eine Schicht den alten Stand. Wir binden die Leerung des Cloudflare-Caches an die Ereignisse im Shop an, statt auf den Ablauf zu warten.
Nicht zwingend. Unsere Server in Deutschland sind gehärtet und überwacht. Cloudflare bringt eine zusätzliche Verteidigungslinie vor dem Server und fängt Massenverkehr ab, bevor er Ihre Ressourcen kostet — für Shops mit Zahlungsverkehr, internationalem Publikum oder häufigen Aktionen empfehlen wir es. Für einen kleinen Shop mit regionalem Publikum besprechen wir es offen.
Ihnen. Die Zone läuft in Ihrem Konto, wir werden als Mitglied eingeladen. Domains, Zertifikate und Regeln bleiben bei Ihnen, auch wenn sich unsere Zusammenarbeit ändert. Eine bestehende Zone übernehmen wir, wie sie ist, und räumen auf.
Für einen bestehenden Shop ist die Einrichtung überschaubar — den Aufwand nennen wir nach dem Blick in Shop und Zone, weil er von der Zahl der Schnittstellen und Zahlungsanbieter abhängt. Die Umstellung selbst planen wir außerhalb Ihrer Stoßzeiten, mit Testbestellungen über jeden Zahlungsweg, bevor der Shop wieder frei ist.
Anfrage
Egal ob noch nichts eingerichtet ist oder der Shop schon hinter Cloudflare läuft und Probleme macht: Wir sehen zuerst hin, dann sagen wir, was zu tun ist.