Die ?q= Flood überstehen: Wie Crawler-Traffic PrestaShop Faceted Search zum DoS-Risiko macht

Sie wachen mit einer Reihe Kunden-E-Mails auf, die fragen, warum die Website um 3 Uhr nachts down war. Die Bestellzahl ist normal, die Fehlerseite erscheint nur zeitweise, und Ihr Admin-Dashboard sieht gut aus. Der Hoster schickt ein Diagramm: MySQL-Verbindungen am Limit, alle PHP-FPM-Worker belegt. Keine der Anfragen kam von echten Kunden.

Wenn Sie einen PrestaShop-Shop mit Faceted Search (Layered Navigation) betreiben und dieses Muster noch nicht getroffen hat, wird es das sehr wahrscheinlich tun. Die Form des Problems ist langweilig, die Ursache strukturell, und der richtige Fix ist nicht der, zu dem die meisten Shopbetreiber zuerst greifen. Dies ist ein Write-up, wie man sich tatsächlich dagegen verteidigt — konkret gegen die ?q= flood: den Moment, in dem gewöhnlicher Crawler-Traffic Ihre eigene Faceted Search in eine selbst verursachte Denial-of-Service-Fläche verwandelt. Dieser Beitrag ist der Deep Dive zu genau diesem Failure Mode; wenn Sie das größere Bild wollen, ist unsere PrestaShop Security Hardening Checklist der Hub, der alle Schichten verbindet.

Das Symptom

Logs zeigen tausende Requests auf URLs wie /category-slug?q=Brand-Brand-A/Brand-Brand-B/Color-Red, jede leicht anders, von rotierenden IPs und einer Mischung deklarierter User-Agents. Manche behaupten Bingbot zu sein, manche Chrome, manche nennen sich GPTBot, ClaudeBot oder PerplexityBot. Die Kategorie-URL selbst ist legitim — es ist Ihre eigene Faceted Search, die Marken- und Attributfilter als Query-String-Parameter ausgibt — aber Volumen und kombinatorische Vielfalt der Requests sind es nicht.

Die PrestaShop-Foren haben Berichte dieses Musters von Shopbetreibern mit 1.7.x und 8.x über 2024 und 2025 gesammelt. Die Form ist konsistent: ein einzelner Thread dokumentiert Betreiber, die zehntausende eindeutige ?q=-URLs pro Tag gecrawlt sehen, während der Controller weiterhin antwortet, selbst nachdem das Modul ps_facetedsearch deaktiviert wurde.

Das Erste, was die meisten Betreiber versuchen, ist das Deaktivieren des Faceted-Search-Moduls. Es hilft nicht. ps_facetedsearch stellt die Filter-UI im Storefront bereit, aber ein GET-Request auf /category-slug?q=anything bootet weiterhin PrestaShop, dispatcht zum Category Controller und läuft durch den Request Lifecycle. Der Query String ist eine gültige Request-Form, egal ob das Modul, das diese URLs erzeugt hat, aktuell aktiviert ist. Das Modul zu deaktivieren versteckt die Filter-Sidebar vor menschlichen Besuchern; es verhindert nicht, dass automatisierte Clients weiter URLs anfragen, die sie bereits entdeckt haben.

Warum das Volumen wächst

Die kombinatorische Natur von Faceted-Search-URLs gibt es, seit das Modul existiert. Neu ist die Größenordnung automatisierten Traffics, der sie findet und crawlt.

Cloudflares Analyse vom Juli 2025 zum Crawler-Traffic im eigenen Netzwerk berichtete:

• Crawler-Traffic plus 18% year over year, mit Peaks von 32% im April 2025.
• Googlebot: +96% Wachstum, von rund 30% auf 50% des gesamten Crawl-Traffics.
• GPTBot: +305% Wachstum, 2,2% auf 7,7% Anteil.
• PerplexityBot: praktisch null zu relevant innerhalb eines Jahres.
• ClaudeBot: nach Änderungen Anfang 2025 46% weniger Requests.
• Bytespider: minus 85%.

Die Zusammensetzung verschiebt sich von Monat zu Monat, der Trend nicht: mehr Crawler, mehr URLs, häufiger. Eine Kategorie-Seite, die ein paar hundert Filterkombinationen erzeugt, wird zum Ziel für alles von Googlebot, der strukturierte Datenindizes baut, bis zu AI-Training-Scrapern, die Produktattribute sammeln. Cloudflare selbst begann Mitte 2025, AI-Training-Bots auf neuen Zonen standardmäßig zu blockieren, was zeigt, wie die Plattform die Entwicklung liest.

Über diesem legitimen Crawler-Traffic liegt eine kleinere, aber aggressivere Schicht feindlicher Automation: Scraper, Competitive-intelligence-Bots und Stress-test-Traffic. Sie respektieren robots.txt nicht, rotieren IPs aggressiv und fälschen legitime User-Agent-Strings. Sie sind diejenigen, die die Site umwerfen. Diese breitere Klasse unerwünschter Automation zu stoppen — nicht nur die ?q= flood — ist eine eigene Disziplin; den allgemeinen Ansatz behandeln wir in Blocking Bad Bots and Unwanted Traffic.

Warum die offensichtlichen Fixes nicht funktionieren

Die meisten Community-Ratschläge fallen in eine von fünf Schubladen. Keine reicht für sich allein.

Das Faceted-Search-Modul deaktivieren. Entfernt die UI, lässt die URL-Fläche bestehen. Der Category Controller beantwortet weiterhin ?q=-Requests.

Disallow: /*?q= zu robots.txt hinzufügen. Googlebot hält sich weitgehend daran. Bingbot tut es inkonsistent — es gibt öffentliche Berichte, dass er disallowed Query-Muster trotzdem crawlt. AI-Crawler respektieren robots.txt je nach Betreiber sehr unterschiedlich. Feindliche Scraper ignorieren sie vollständig. Sinnvoll, nie ausreichend.

Ein pauschaler .htaccess-Block für jede URL mit ?q=. Das erwischt Bots, bricht aber auch Ihre eigenen AJAX-Filter-Requests (dasselbe URL-Muster, das Ihr Storefront nutzt, um Filterergebnisse ohne Page Reload zu laden) und jede gespeicherte oder geteilte Filter-URL echter Kunden. Der SEO-Schaden potenziert sich, falls Google einige dieser Filterseiten als Canonical für Long-tail-Queries indexiert hatte. Es gibt einen Platz für handgetunte Serverregeln — nur keinen Vorschlaghammer; unsere PrestaShop .htaccess security and performance rules behandeln die Regeln, die sich lohnen.

Bestimmte Bot-User-Agents blockieren. Whack-a-mole. Neue Bots erscheinen wöchentlich, feindliche Bots fälschen UA-Strings, und legitime AI-Referrer (ChatGPT, Perplexity, Copilot), die einen wachsenden Anteil eingehender Klicks bringen, würden ebenfalls blockiert. Das Crawl-to-click-Verhältnis ist bei AI-Bots weiterhin schlecht, aber nicht null — Cloudflares eigene Daten zeigen, dass Referrals existieren.

Full-page caching von ?q=-URLs. Die Cache-Hit-Rate ist fast null, weil jede Filterkombination eine eindeutige URL ist. Sie cachen 50.000 Seiten und liefern jede einmal aus. Der Cache wird zu einem Write-amplification-Problem statt zu einer Read-Abkürzung.

Die verbleibende Option — und darum geht es im Rest dieses Beitrags — ist, die Entscheidung, wer diese URLs treffen darf, vollständig vor PrestaShop zu verlagern, wo sie billig und ohne PHP-Boot getroffen werden kann.

Der richtige Fix: eine Cloudflare Managed Challenge auf die Faceted-Search-Form

Cloudflares Managed Challenge ist für dieses Problem aus drei Gründen das richtige Werkzeug. Sie ist meistens nicht interaktiv (Menschen passieren transparent), sie erfordert keine Liste konkreter Bots, und sie lässt die eigenen AJAX-Filteraufrufe Ihres Storefronts funktionieren, indem sie auf eine Request-Form matcht, die Automation nicht trivial nachahmen kann.

Das Muster sind zwei Custom Rules (paid Bot Management) oder eine (Free Tier), ausgewertet gegen jeden GET, der den Query-Parameter q enthält.

Wenn Sie Bot Management haben (paid)

Regel 1 — verifizierte Bots überspringen. Match auf den Ausdruck cf.client.bot, mit Action Skip remaining custom rules. Dadurch kommen Googlebot, Bingbot und jeder andere von Cloudflare verifizierte Crawler ohne Challenge durch. Verified-bot-Erkennung basiert auf Reverse DNS und signierten IP-Ranges, nicht auf User-Agent-Strings, daher matcht ein feindlicher Scraper mit gefälschtem "Mozilla/5.0 (compatible; Googlebot/2.1)" nicht.

Regel 2 — wahrscheinliche Automation auf der Faceted-Search-Form challengen. Der Ausdruck, über seine logischen Klauseln geschrieben, lautet:

• http.request.method eq "GET"
• und len(http.request.uri.args["q"]) >= 0 — der Request trägt einen q-Parameter
• und not cf.client.bot — es ist kein verifizierter Crawler
• und not any(lower(http.request.headers["x-requested-with"][*])[*] eq "xmlhttprequest") — es ist nicht der eigene AJAX-Filteraufruf des Storefronts
• und not starts_with(http.request.uri.path, "/module/")
• und not starts_with(http.request.uri.path, "/api/")
• und cf.bot_management.score gt 1 and cf.bot_management.score lt 30 — der Request landet im Band "wahrscheinlich Automation, noch nicht sicher"

Action: Managed Challenge. In einfachem Deutsch: Ein GET-Request mit q-Query-Parameter, der kein verifizierter Bot ist, nicht der eigene AJAX-Filteraufruf des Storefronts ist (der X-Requested-With: XMLHttpRequest sendet), kein Modul- oder API-Endpunkt ist und als wahrscheinliche Automation scored — wird gechallenged. Menschen bekommen einen One-click Pass; Automation stoppt am Edge.

Wenn Sie bei eindeutig automatisiertem Traffic strenger sein möchten, fügen Sie vor Regel 2 eine Regel hinzu, die dieselbe GET-mit-q, non-verified-bot-Form matcht, aber mit cf.bot_management.score eq 1 — Cloudflares Bewertung "this is automation, full stop". Action: Block (vertretbar) oder Managed Challenge, je nach Risikobereitschaft.

Wenn Sie kein Bot Management haben (Free- oder Pro-Plan)

Der Cloudflare-Ausdruck sollte die Faceted-Search-Form matchen, nicht jede Kategorie-URL. Starten Sie im Log-Modus oder mit Managed Challenge, bevor Sie blockieren:

(http.request.uri.query contains "q=" and http.request.uri.path contains "/category")
or
(http.request.uri.path matches "^/[^?]+/q-[^/]+")

Auf Free-Plänen gibt es kein Äquivalent zum Bot Score. Das alte Feld cf.threat_score, das ältere Guides empfehlen, ist inzwischen dauerhaft auf 0 gesetzt — Cloudflare hat es deprecated. Verschwenden Sie keine Zeit mit Regeln, die es referenzieren.

Ohne Bot Score fallen Sie auf Matching nach Request-Form zurück. Starten Sie konservativ mit einer einzelnen Regel, die feuert auf: einen GET-Request, bei dem len(http.request.uri.args["q"]) >= 0, und not cf.client.bot, und der Request ist kein AJAX-Call (kein Header X-Requested-With: XMLHttpRequest), und der Pfad beginnt nicht mit /module/ oder /api/. Action: Managed Challenge.

Das challengt jeden non-AJAX, non-verified-bot GET mit q-Parameter. Echte Kunden, die eine gespeicherte Filter-URL laden, sehen kurz eine Managed Challenge und passieren sie. Bookmarked Links funktionieren weiter. Crawler-Traffic wird am Edge abgeschnitten. Der Preis ist ein zusätzlicher Round-trip für menschliche Besucher, die über Bookmark oder geteilten Link auf einer Faceted URL landen.

Wichtige Einschränkungen, bevor Sie das einschalten

Testen Sie zuerst in Log-only / Security Events. Setzen Sie die Rule Action mindestens 24–48 Stunden auf "Log" und beobachten Sie Cloudflares Security Events Dashboard. Sie suchen zwei Dinge: dass die Regel auf den erwarteten Traffic feuert (viel davon), und dass sie nicht auf legitime Pfade feuert, die Sie vergessen haben — Sitemap-Fetcher, Analytics-Tools, ein Custom Module, das aus irgendeinem Grund ?q= in eigenen URLs nutzt. Erst nach sauberem Matcher auf Managed Challenge umstellen.

Die X-Requested-With-Ausnahme ist UX-Erhalt, keine Security Boundary. Jeder HTTP-Client kann diesen Header senden. Ein Angreifer, der die Regel erkennt, kann sie durch Hinzufügen des Headers umgehen. Der Grund für die Regel ist, dass die eigenen Filter-AJAX-Aufrufe Ihres Storefronts ohne Challenge durchkommen — nicht, um entschlossene Automation draußen zu halten. cf.client.bot und Bot-score-Checks stoppen Automation tatsächlich; die AJAX-Ausnahme hält nur echte Nutzer auf derselben Seite, wenn sie Filter klicken.

Proxyen Sie jeden öffentlichen Web-Hostnamen (orange cloud) — aber behandeln Sie Mail und Non-HTTP-Records korrekt. Mail/MX und andere Non-HTTP-Records dürfen im Allgemeinen nicht durch Cloudflare proxied werden, und der orange-cloud Proxy kann Non-HTTP-Dienste nicht genauso schützen. Das eigentliche Risiko ist jeder DNS-only (grey-cloud) Record — mail, dev, ein Admin-Subdomain — der auf denselben Server wie der Shop zeigt, weil er die Web-Origin-IP leakt. Wer den Origin findet, kann Cloudflare komplett umgehen und PrestaShop direkt treffen. Halten Sie Mail und andere Non-HTTP-Records DNS-only, aber stellen Sie sicher, dass sie nicht auf die Web-Origin-IP zeigen oder sie verraten — verschieben Sie Mail, dev und Admin auf separate IPs oder beschränken Sie sie. Auditieren Sie Ihr DNS-Panel, bevor Sie der WAF vertrauen.

Beschränken Sie den Origin auf Cloudflare-IPs. Selbst wenn alles proxied ist, blockieren Sie den Origin per Firewall hart so, dass HTTP/HTTPS nur von Cloudflares veröffentlichten IP-Ranges angenommen wird. Sonst kann ein Angreifer, der die Origin-IP aus alter DNS-Historie lernt, sie direkt treffen. Während Sie den Origin-Zugriff einschränken, stellen Sie sicher, dass der Origin Ende-zu-Ende HTTPS-only ist — unser Walkthrough zum Einrichten von SSL und HTTPS in PrestaShop deckt Zertifikat und Redirects ab, damit Edge und Origin übereinstimmen.

Wenn Sie auf AI-Search-Referrals angewiesen sind, beobachten Sie die Auswirkungen. Manche AI-Crawler sind auch Teil des Referral-Pfads, der Kunden über ChatGPT-, Perplexity- und Copilot-Links bringt. Eine pauschale Challenge reduziert Crawl-Traffic und (in kleinerem Maß) eingehende Referrals. Für einen E-Commerce-Shop lohnt sich der Trade-off meist, aber es ist ein Trade-off — prüfen Sie Ihre Analytics nach einer Woche.

Der Fallback: ein Dispatcher Override

Wenn Sie Cloudflare heute nicht deployen können — weil Sie DNS nicht kontrollieren, weil die CDN-Integration Ihres Hosts fragil ist, weil ein Payment-Modul mit proxied Origins inkompatibel ist oder weil die Blutung in den nächsten zehn Minuten stoppen muss — ist der In-PHP-Fallback ein Dispatcher Override, der non-AJAX-?q=-Requests per 301 auf dieselbe URL ohne Filter zurückleitet.

Sie platzieren ihn unter override/classes/Dispatcher.php. Die Klasse erweitert DispatcherCore und überschreibt dispatch(). Die Logik: Wenn Tools::getValue('q') vorhanden ist und der Request kein AJAX-Call ist (die Server-Variable HTTP_X_REQUESTED_WITH ist leer oder nicht xmlhttprequest), dann $_SERVER['REQUEST_URI'] parsen, den Key q aus den Query-Parametern entfernen, die URL mit http_build_query() gegen Tools::getShopDomainSsl(true) neu bauen, einen 301-Location-Header zur bereinigten URL senden und exit. Sonst unverändert parent::dispatch() zurückgeben.

Was das tut: Jeder direkte Browser-, non-AJAX-Request auf eine URL mit ?q= wird per 301 auf denselben Pfad ohne q-Parameter umgeleitet. AJAX-Requests (die eigenen Filteraufrufe des Storefronts) passieren unverändert. Die Faceted-Filter-UI funktioniert für echte Kunden weiter; die URL-Fläche, die Bots crawlen, kollabiert auf eine einzige Canonical-Kategorieseite. (Ein Override unter override/classes/Dispatcher.php ist ein unterstützter PrestaShop-Extension-Point — er überlebt Modul-Updates, aber denken Sie daran, nach dem Ablegen der Datei den Class-index-Cache zu leeren, sonst lädt PrestaShop weiter die Core-Klasse.)

Drei Trade-offs, die Sie vor dem Deployment verstehen sollten:

• SEO-Auswirkung. Wenn Google einige Ihrer Filter-URLs als Canonical für Long-tail-Queries ("blue running shoes size 9") indexiert hat, brechen diese Rankings ein — jede indexierte Filter-URL redirectet jetzt auf die ungefilterte Kategorie. Für die meisten Shops ist das akzeptabel; die ursprünglichen Facet-URLs waren meist ohnehin schwache Rankings. Prüfen Sie aber Search Console vor dem Deployment und erwägen Sie einen einmaligen Export hochwertiger Filter-URLs, die Sie behalten möchten, mit expliziten 301-Maps auf dedizierte Landing Pages.
• Bookmarks und Shares. Ein Kunde, der eine Filter-URL gespeichert oder geteilt hat, landet nicht mehr auf der gefilterten Ansicht. Der Cloudflare-Managed-Challenge-Ansatz erhält das; der Dispatcher Override nicht.
• Er hilft nur gegen PHP-seitige Last. Der Request trifft weiterhin PHP — er beendet nur schnell mit 301 statt die komplette Kategorie-Seite auszuführen. Wenn Ihr Bottleneck Connection Count statt CPU ist, hilft das weniger als der Edge-level-Fix.

Deployen Sie ihn als Stopgap. Wechseln Sie so schnell wie möglich zu Cloudflare.

Edge versus Origin: welcher Fix für welchen Bottleneck

Die zwei Verteidigungen sind nicht austauschbar. Wählen Sie nach der Stelle, an der Ihr Shop tatsächlich leidet.

Wenn Sie beides tun können, tun Sie beides: Die Edge-Regel trägt die Last, und der Override ist Ihr Sicherheitsnetz für das Fenster vor DNS-Propagation oder falls Sie den Proxy je entfernen müssen.

Der architektonische Blick: die URL-Fläche selbst ersetzen

Indexierbare Filterseiten sollten bewusste URLs sein, keine zufälligen Crawler-Kombinationen.

Beide Fixes oben schützen die bestehende ps_facetedsearch-URL-Fläche vor Automation. Keiner ändert die Tatsache, dass das Modul überhaupt einen kombinatorisch großen öffentlichen URL-Raum ausstellt.

Eine andere Klasse von Filtermodul vermeidet das Problem an der Quelle: Filterzustand lebt clientseitig (oder in einem einzelnen AJAX POST), die öffentliche URL bleibt sauber, und nur bewusst kuratierte SEO-Landingpages — eine handgebaute Seite für "men's running shoes" statt jede Marken-Farb-Größen-Kombination — werden indexierbar. Wir haben Filter Revolution in diesem Stil gebaut, teilweise als Antwort auf genau die hier beschriebenen Traffic-Muster. Was bedeutet das für Sie? Es verkleinert die high-cardinality öffentliche URL-Fläche, die ps_facetedsearch für Crawler attraktiv macht, also weniger kombinatorische Seiten für Bots und weniger 3-Uhr-Nachrichten vom Hoster — aus dem Back Office konfiguriert, ohne Ihr Theme zu forken. Es ist kein magischer Schild gegen AI-Crawler — nichts ist das — und es entfernt nicht rückwirkend URLs, die Google und Bing bereits gefunden haben. Aber es entfernt die strukturelle Angriffsfläche, um die Cloudflare- und Dispatcher-Fixes herumarbeiten.

Wenn Sie es leid sind, das Symptom zu patchen, und ohnehin eine Faceted-Search-Überarbeitung ansteht, schauen Sie auf den Austausch des Moduls statt auf das Einwickeln. Wenn das bestehende Modul zum Shop passt, wird die Cloudflare-Regel oben dauerhaft funktionieren.

Noch etwas: die leeren Warenkörbe

Jeder Bot-Request, der die Kategorie-Seite trifft, triggert auch PrestaShops Session- und Warenkorb-Bootstrap. Jeder eindeutige automatisierte Besucher bekommt eine ps_cart-Zeile. Nach einem Monat Crawler-Traffic zeigt Ihr Back-Office-Warenkorbzähler 80.000 "aktive" Warenkörbe, Ihre warenkorbbezogenen Admin-Seiten werden quälend langsam, und jeder Abandoned-cart-Workflow wird unbrauchbar, weil fast keiner dieser Warenkörbe je einem Menschen gehörte.

Wenn Sie die Cloudflare-Regel bereits deployed haben, wächst das nicht weiter — aber die bestehende Verschmutzung bereinigt sich nicht von selbst, und PrestaShops eingebaute Cart-cleanup-Tasks sind nicht aggressiv genug für Monate angesammelter Bot-Warenkörbe. Der pragmatische Fix ist, anonyme Bot-Origin-Warenkörbe aus Back-Office-Zählern und Listings auszublenden statt sie zu löschen: Die Zeilen bleiben für ihren forensischen Wert in der Datenbank, verschmutzen aber die UI nicht mehr. Das ist ein anderes Problem als die Flood selbst, und wir behandeln es als eigene Aufgabe — wenn Ihr Warenkorb-Admin bereits unter Bot-Warenkörben begraben ist, ist diese Bereinigung parallel zur Edge-Regel auszuführen, nicht statt ihr.

Wo das in Ihre breitere Verteidigung passt

Die ?q= flood ist ein spezifischer Failure Mode, aber die Control Plane, die Sie dagegen bauen, zahlt sich über den Rest Ihrer Security Posture aus. Ein paar angrenzende Aufgaben, die nach der Edge-Regel anstehen:

• Per-visitor Blocking und IP-Bans. Wenn eine einzelne Quelle nach der Challenge weiter probt, brauchen Sie eine saubere Möglichkeit, sie abzuschneiden und zu sehen, wer Sie trifft — siehe Customer Extra Info and IP Bans.
• Form Spam, getrennt von Traffic Floods. Dieselbe Automation, die Facets crawlt, wird auch Kontakt- und Registrierungsformulare hämmern; eine Challenge bei Submission ist dort die Antwort — siehe reCAPTCHA for PrestaShop.
• Wenn Sie den Core noch nicht upgraden können. Shops auf älterem PrestaShop haben weniger native Hebel; der Edge-and-override-Ansatz hier ist Teil einer breiteren Virtual-patching-Strategie in Advanced Hardening for Stores You Can't Upgrade Yet.
• Neu in all dem. Wenn die Begriffe oben viel sind, starten Sie mit dem Plain-English Guide for Store Owners und arbeiten Sie sich von dort hoch.

Kurze Checkliste

• Cloudflare für die Domain aktivieren. Jeden öffentlichen Web-Hostnamen proxyen (orange cloud); Mail und andere Non-HTTP-Records DNS-only lassen und sicherstellen, dass sie nicht auf die Web-Origin-IP zeigen oder sie verraten.
• Regel 1 (verified bots skippen) und Regel 2 (Managed Challenge auf Faceted-Form) im Log-only-Modus hinzufügen. Security Events 24–48 Stunden beobachten.
• Bestätigen, dass legitime AJAX-Filteraufrufe nicht gechallenged werden. Bestätigen, dass Googlebot die Site erreicht. Bestätigen, dass Scraper-Traffic gematcht wird.
• Regel 2 von Log auf Managed Challenge umstellen.
• Origin-Firewall auf Cloudflare-IP-Ranges beschränken. Das schließt den Kreis.
• Wenn Cloudflare keine Option ist, Dispatcher Override als Stopgap deployen und Migration planen.
• Wenn eine Filtermodul-Überarbeitung ansteht, den vollständigen Ersatz von ps_facetedsearch prüfen.
• Back-Office-Warenkorbverschmutzung separat bereinigen, damit der Cart Admin nutzbar bleibt.

Abschluss

Das ist die neue Baseline. Faceted-search-URL-Explosion trifft AI-era-Crawler-Volumen, und das Ergebnis ist eine selbst verursachte DoS-Fläche, die auf jeder PrestaShop-Installation out of the box mitgeliefert wird. Die Defaults retten Sie nicht, die offensichtlichen Workarounds brechen legitime Nutzer, und "Bots blockieren" wird jeden Monat schwieriger, weil die Bots besser werden.

Die gute Nachricht: Der richtige Fix lebt am Edge, kostet auf einem kostenlosen Cloudflare-Plan nichts und braucht etwa dreißig Minuten, wenn man ihn sorgfältig deployed. Die schlechte Nachricht: Es ist eine weitere Sache, die Sie letztes Jahr hätten tun sollen. Die kumulierende Nachricht: Die Arbeit trägt weiter. Sobald Sie einen sauberen Origin hinter einer getunten WAF haben, wird die nächste Klasse automatisierter Störungen — Credential Stuffing, Scraping, Fake-checkout Floods — deutlich leichter aus derselben Control Plane zu verteidigen.

Für den vollständigen Layered Approach kehren Sie zur PrestaShop Security Hardening Checklist zurück. Was passiert, wenn ein Shop durch etwas Anspruchsvolleres als Crawler Abuse kompromittiert wird, zeigt die Anatomie eines Magecart-artigen Angriffs auf einen PrestaShop-1.7.x-Shop. Das defensive Playbook hat in beiden Fällen dieselbe Form: billige Controls am Edge, enge Ausnahmen dort, wo sie nötig sind, und absolut keine Security Claims, die auf User-Agent-Strings beruhen.