reCAPTCHA für PrestaShop: So schützen Sie Ihren Shop vor Spam und Bots

Zuletzt aktualisiert: Juni 2026.

Ein PrestaShop-Shop ohne CAPTCHA ist kein hypothetisches Risiko. Er ist ein Ziel, das automatisierter Traffic von selbst findet. Bots durchsuchen das Web nach den standardmäßigen PrestaShop-Formular-Endpunkten, und sobald sie Ihren gefunden haben, nehmen sie ihn unter Beschuss: gefälschte Registrierungen über den AuthController, Müll im Kontaktformular, Passwortkombinationen gegen die Anmeldung, Fluten von E-Mails zum Zurücksetzen des Passworts. Dafür muss niemand überhaupt wissen, dass Ihr Shop existiert. Die Formulare werden mit PrestaShop ausgeliefert, die Bots kennen diese Formulare, und eine Standardinstallation von PrestaShop bietet dafür überhaupt keinen Bot-Schutz.

In diesem Leitfaden geht es darum, genau diese Lücke zu schließen: was Bots in einem PrestaShop-Shop tatsächlich tun, welche konkreten Formulare sie angreifen und wie CAPTCHA jeden dieser Angriffe stoppt. Wenn Ihre Sorge die andere Seite ist, Schutz hinzuzufügen, ohne echte Kunden mit störenden Prüfungen zu vertreiben, ist das eine Conversion-Frage, die wir separat in reCAPTCHA ohne Verärgerung echter Kunden behandeln. Hier liegt der Schwerpunkt auf Bedrohung und Abwehr.

Was Bots in einem PrestaShop-Shop tatsächlich tun

"Spam und Bots" klingt abstrakt, bis Sie es im eigenen Backoffice sehen. So zeigt es sich in einer echten PrestaShop-Installation, zugeordnet zu dem Bereich des Shops, den es beschädigt.

Der gemeinsame Nenner all dieser Fälle: Der Schaden ist selten ein spektakulärer Einbruch. Es ist langsamer Verfall. Eine Kundendatenbank, der Sie nicht mehr vertrauen können, ein Support-Postfach, das Sie nur noch widerwillig öffnen, eine E-Mail-Reputation, die leise absinkt. CAPTCHA auf den richtigen Formularen stoppt den Großteil davon direkt an der Tür. (Für das ernstere Ende des Spektrums: Credential Stuffing, Bestell- und Kartenmissbrauch sowie Skimmer, ist CAPTCHA nur eine von mehreren Schutzschichten; siehe die vollständige Checkliste zur Sicherheits-Härtung und die Anatomie eines Magecart-ähnlichen Angriffs.)

Welche PrestaShop-Formulare Sie schützen sollten, und welche nicht

Der Reflex, "CAPTCHA überall einzubauen", ist der falsche. Bots konzentrieren sich auf eine Handvoll Endpunkte, und jedes geschützte Formular bringt etwas Reibung mit. Schützen Sie dort, wo die Angriffe landen, nicht nach Bauchgefühl.

Zuerst schützen, hier sitzen die Bots

• Registrierungsformular. Das wichtigste Bot-Ziel in jedem PrestaShop-Shop. Ohne Schutz wächst hier der Berg gefälschter Konten. Nicht verhandelbar.
• Kontaktformular. Das am zweithäufigsten getroffene Ziel. Es ist die Grenze zwischen Ihnen und einem Kundenservice-Postfach voller Rauschen.
• Anmeldeformular. Verhindert, dass Brute-Force-Versuche sowohl zum Serverlastproblem als auch zum Problem kompromittierter Konten werden.

Als Nächstes schützen

• Passwort zurücksetzen. Schließt den Vektor für Fluten von Zurücksetzen-E-Mails, der Ihre Absenderreputation nach unten zieht.
• Newsletter-Anmeldung. Hält gefälschte Anmeldungen aus Ihrer Liste heraus.
• Produktbewertungen (wenn Sie ein Bewertungsmodul verwenden). Bots veröffentlichen gefälschte Bewertungen, um Bewertungen zu manipulieren.

In Ruhe lassen, sofern kein nachgewiesenes Problem besteht

• Kasse. Ein sichtbares CAPTCHA an der Kasse ist eine selbst verursachte Wunde, es erhöht die Abbruchrate auf der wertvollsten Seite Ihres Shops. Greifen Sie nur ein, wenn Sie echte Kassenbetrugsfälle sehen, und dann ausschließlich mit unsichtbarem Scoring (niemals mit Checkbox). Die Abwägungen dazu sind genau das Problem "echte Kunden nicht verärgern", das wir im begleitenden Leitfaden behandeln.
• Suchfeld und In-den-Warenkorb-Legen. Selten ein echtes Ziel; die Reibung ist es nicht wert.

reCAPTCHA v2 vs. v3 vs. hCaptcha, welchen Schutz Sie einsetzen sollten

Die gewählte Version verändert sowohl, wie schwer Bots durchkommen, als auch, wie stark echte Kunden etwas davon bemerken. Drei realistische Optionen für einen PrestaShop-Shop:

Für die meisten PrestaShop-Shops geht es um die Wahl zwischen v3 für unsichtbares Scoring und v2 oder hCaptcha für eine explizite Prüfung. Das aktuelle Modul mprrecaptcha lässt Sie reCAPTCHA v2, reCAPTCHA v3 oder hCaptcha wählen und den v3-Score-Schwellenwert festlegen; es fällt bei grenzwertigen Scores nicht automatisch von v3 auf v2 zurück. Der Umgang mit niedrigen Scores ist also eine Frage von Tuning und Ablehnung, nicht einer zweiten Prüfung. Welchen Schwellenwert Sie setzen sollten und wie Sie vermeiden, echte Menschen auszusperren, ist die Feinabstimmung dieses Themas, behandelt im begleitenden Leitfaden.

CAPTCHA in PrestaShop-Formulare bringen, die Mechanik

PrestaShop liefert kein CAPTCHA mit, also bedeutet Schutz: ein Modul. Entscheidend ist, wie es eingebunden wird, denn das bestimmt, ob es eine Übermittlung tatsächlich blockiert oder das Formular nur dekoriert.

Schritt 1, Ihre Schlüssel erzeugen

Für reCAPTCHA registrieren Sie die Website unter www.google.com/recaptcha/admin; für hCaptcha im hCaptcha-Dashboard. In beiden Fällen erhalten Sie einen öffentlichen Site Key (wird auf der Seite gerendert) und einen privaten Secret Key (wird serverseitig zur Prüfung verwendet). Fügen Sie sowohl Ihre www- als auch Ihre Nicht-www-Domain hinzu. Schlüssel sind an Domains gebunden. Eine nicht passende Domain kann die CAPTCHA-Validierung brechen oder legitime Übermittlungen blockieren. Registrieren Sie deshalb pro Umgebung ein separates Schlüsselpaar und testen Sie, dass das Formular sicher fehlschlägt (also ablehnt, statt Übermittlungen still durchzulassen), wenn das Token nicht verifiziert wird.

Schritt 2, wie ein ordentliches Modul sich einklinkt

Die wichtigen Einstellungen sind Anbieter, Schlüssel, geschützte Formulare und v3-Schwellenwert.

In einem echten Modul rendern die Display-Hooks das Widget, und die Action-Hooks lehnen die Übermittlung ab, bevor PrestaShop das Konto, die Nachricht oder das Abonnement erstellt. Dies sind die relevanten Hooks aus dem Quellcode von mprrecaptcha.

public function getHooks()
{
    return [
        'displayHeader',
        'displayFooter',
        'displayCustomerLoginFormAfter',
        'displayCustomerAccountForm',
        'displayNewsletterRegistration',
        'displayGDPRConsent',
        'actionContactFormSubmitBefore',
        'actionSubmitAccountBefore',
        'actionCustomerLoginBefore',
        'actionNewsletterRegistrationBefore',
    ];
}

Genau dieser Teil trennt echten Schutz von Theater. Ein Bot füllt Ihr Formular nicht von Hand aus; er sendet einen POST direkt an den Controller. Deshalb muss die Prüfung serverseitig erfolgen, bevor PrestaShop die Übermittlung verarbeitet, nicht nur als Widget, das auf der Seite gezeichnet wird. Die zentrale Anforderung ist in jeder Version dieselbe: Das Token wird serverseitig validiert, bevor Konto, Kontaktnachricht, Anmeldung oder Newsletter-Anmeldung verarbeitet werden. Die exakten Hook-Namen unterscheiden sich je nach Zweig, ältere Versionen 1.6/1.7 nutzen andere Front-Controller- und Formularabläufe als 8/9. Ein gut gebautes Modul verbindet sich deshalb mit den jeweils validierten Before-Hooks, die für Ihre Zielversion existieren (zum Beispiel die Hooks für Registrierung, Kontaktformular, Anmeldung und Newsletter-Übermittlung). Welchen Hook es auch verwendet: Es validiert das Token gegen den siteverify-Endpunkt von Google oder hCaptcha und lehnt die Anfrage ab, bevor überhaupt ein Konto oder eine Nachricht erstellt wird. Die Anzeigeseite läuft über displayCustomerAccountForm, displayCustomerLoginFormAfter und displayHeader/displayFooter, um das Widget einzufügen und das Skript zu laden. Wenn ein Modul nur das Badge rendert, aber die Before-Hooks nicht absichert, läuft ein direkt postender Bot einfach daran vorbei.

Schritt 3, prüfen, ob es wirklich blockiert

Nicht annehmen, testen. Senden Sie jedes geschützte Formular als normaler Kunde ab, um zu bestätigen, dass legitime Nutzung weiter funktioniert. Prüfen Sie anschließend das Anbieter-Dashboard, um zu bestätigen, dass Verifizierungen protokolliert werden. Der häufigste Konfigurationsfehler ist ein Formular, das geschützt aussieht, dessen Before-Hook aber nicht verdrahtet ist. Dann segeln Bots hindurch, während Sie glauben, abgesichert zu sein.

Die PrestaShop-spezifische Modulwahl

Weil Schutz mit diesen serverseitigen Hooks steht oder fällt, ist das gewählte Modul wichtiger als die CAPTCHA-Marke. Unser Modul mprrecaptcha (PrestaShop 1.6 bis 9) wurde genau dafür entwickelt: Es unterstützt reCAPTCHA v2, v3 und hCaptcha und hängt sich in jedem unterstützten Zweig an die echten serverseitigen Übermittlungs-Hooks der jeweiligen Version für Registrierung, Kontakt, Anmeldung und Newsletter, sodass ein direkter Bot-POST im Controller validiert und abgelehnt wird, statt nur auf der Seite versteckt zu bleiben. Was bedeutet das für Sie? Sie wählen im Backoffice, welche Formulare geschützt werden sollen, lassen die Kasse reibungslos und können gefälschte Registrierungen sowie Kontaktformular-Spam reduzieren, ohne eine Theme-Datei zu bearbeiten oder den Core anzufassen, sodass die Lösung Updates übersteht. Außerdem stellt es einen displayGDPRConsent-Hook bereit, damit das CAPTCHA-Skript in Ihren Einwilligungsfluss eingebunden werden kann, was in der EU wichtig ist (siehe unten).

Der DSGVO-Haken, den Sie nicht überspringen können

Googles reCAPTCHA lädt Google-JavaScript und sendet die IP-Adresse sowie Verhaltensdaten des Besuchers an Google-Server. Das ist unter der DSGVO eine Verarbeitung, die eine Rechtsgrundlage benötigt, und mehrere EU-Datenschutzbehörden (darunter die französische CNIL) haben darauf hingewiesen. Für einen EU-Shop entsteht dadurch eine echte Spannung: Blockieren Sie reCAPTCHA bis zur Cookie-Einwilligung, bleiben Ihre Formulare für Besucher ohne Einwilligung ungeschützt; laden Sie es unabhängig davon, haben Sie ein Compliance-Risiko. Es gibt keine allgemein "richtige" Antwort. Es ist eine Risikoentscheidung. Zwei praktische Wege: Binden Sie CAPTCHA in Ihren Einwilligungsmechanismus ein (dafür existiert der oben genannte displayGDPRConsent-Hook), oder umgehen Sie die Google-Datenübermittlung vollständig, indem Sie hCaptcha verwenden, das keine Daten mit Google teilt. Das ist nur ein Ausschnitt eines größeren Compliance-Bildes; die breitere Händlerperspektive finden Sie im Sicherheitsleitfaden in einfacher Sprache.

CAPTCHA ist eine Schutzschicht, nicht die ganze Mauer

CAPTCHA stoppt automatisierten Formularmissbrauch, gefälschte Konten, Kontakt-Spam, Zurücksetzen-Fluten, Brute-Force-Rauschen. Es stoppt nicht alles, und es als Ihre gesamte Verteidigung zu behandeln, ist ein Fehler. Verteilte Bots mit rotierenden IPs, Traffic-Fluten und Angreifer, die bereits am Formular vorbei sind, brauchen weitere Schichten:

• Bad-Bot- und IP-Blockierung für Traffic, der Ihre Formulare gar nicht erst erreichen sollte, siehe Blockieren schlechter Bots und unerwünschten Traffics und IP-Sperren für problematische Besucher.
• Schutz auf Admin-Seite. CAPTCHA hilft bei der Frontoffice-Anmeldung, aber das Backoffice braucht Zwei-Faktor-Authentifizierung und Passwortrichtlinien: 2FA und Admin-Sicherheit.
• Crawler-getriebene Last, gegen die kein CAPTCHA hilft, etwa die Abfrageflut der facettierten Suche: die ?q=-Flut überstehen.
• Wenn doch etwas durchkommt, das Incident-Playbook in Reaktion auf Datenschutzverletzungen.

Die ehrliche Quintessenz: Bringen Sie CAPTCHA mit einem Modul auf Ihre Registrierungs-, Kontakt- und Anmeldeformulare, das die serverseitigen Before-Hooks absichert, lassen Sie die Kasse in Ruhe, klären Sie die DSGVO-Frage bewusst und betrachten Sie das Ergebnis als eine solide Schicht eines gehärteten Shops, nicht als Ziellinie. So umgesetzt, können gefälschte Konten und Kontaktformular-Spam abnehmen, wodurch sich Ihre Kundendaten und Ihr Postfach leichter verwalten lassen.

Häufig gestellte Fragen

Auf welche Formulare sollte ich CAPTCHA wirklich setzen?

Schützen Sie dort, wo die Bots sind, nicht überall. Die drei ersten sind das Registrierungsformular (das Ziel Nummer eins, so wächst der Berg gefälschter Konten), das Kontaktformular (hält Ihr Kundenservice-Postfach nutzbar) und das Anmeldeformular (stoppt Brute-Force-Rauschen). Nächste Stufe: Passwort zurücksetzen, Newsletter-Anmeldung und Produktbewertungen, falls Sie ein Bewertungsmodul einsetzen. Lassen Sie die Kasse in Ruhe, sofern kein nachgewiesener Betrug vorliegt, ein sichtbares CAPTCHA dort erhöht die Abbruchrate auf Ihrer wertvollsten Seite. Wenn es unbedingt sein muss, nutzen Sie ausschließlich unsichtbares Scoring, niemals eine Checkbox.

reCAPTCHA v2, v3 oder hCaptcha, was sollte ich wählen?

v3 ist unsichtbar und bewertet Verhalten mit 0.0–1.0 anhand eines von Ihnen festgelegten Schwellenwerts. Das passt zu stark frequentierten oder conversion-sensiblen Formularen, erfordert aber sorgfältiges Tuning, damit Sie echte Menschen bei niedrigen Scores nicht ablehnen. v2 und hCaptcha zeigen eine explizite Prüfung, was bei Kontakt- und Registrierungsformularen in Ordnung ist, wenn ein kleiner Klick akzeptabel ist. Der entscheidende Unterschied von hCaptcha für EU-Shops ist, dass es keine Daten an Google sendet. Das Modul mprrecaptcha unterstützt alle drei und lässt Sie den v3-Score-Schwellenwert festlegen; es wechselt bei grenzwertigen Scores nicht automatisch von v3 auf v2, daher ist der Umgang mit niedrigen Scores eine Tuning- und Ablehnungsentscheidung.

Mein Formular sieht geschützt aus, aber Spam kommt trotzdem durch, was stimmt nicht?

Fast immer ist die Verifizierung dekorativ, nicht durchgesetzt. Ein Bot füllt Ihr Formular nicht von Hand aus, er sendet einen POST direkt an den Controller. Wenn das Modul also nur das Widget auf der Seite rendert, aber die serverseitigen Before-Hooks nicht absichert (die Hooks für Registrierung, Kontakt, Anmeldung und Newsletter-Übermittlung), läuft ein direkter POST einfach daran vorbei. Echter Schutz validiert das Token gegen den siteverify-Endpunkt des Anbieters, bevor Konto, Nachricht oder Abonnement erstellt werden. Testen Sie es: Senden Sie jedes Formular als normaler Kunde ab, um zu bestätigen, dass es weiterhin funktioniert, und prüfen Sie anschließend das Anbieter-Dashboard, um zu bestätigen, dass Verifizierungen protokolliert werden.

Warum "funktioniert CAPTCHA nicht mehr", nachdem ich Domains umgezogen oder www hinzugefügt habe?

reCAPTCHA- und hCaptcha-Schlüssel sind an Domains gebunden. Wenn Ihr Site Key und Ihr Secret Key für einen Host registriert wurden, validieren sie auf einem anderen nicht, eine nicht passende oder fehlende www- bzw. Nicht-www-Eintragung kann also die Validierung brechen oder legitime Übermittlungen blockieren. Fügen Sie sowohl Ihre www- als auch Ihre Nicht-www-Domains zum Schlüssel hinzu und registrieren Sie pro Umgebung (Staging vs. Produktion) ein separates Schlüsselpaar. Bestätigen Sie außerdem, dass das Formular sicher fehlschlägt. Also Übermittlungen ablehnt, wenn das Token nicht verifiziert wird, statt sie still durchzulassen.

Ist Google reCAPTCHA für einen EU-Shop ein DSGVO-Problem?

Es ist eine echte Risikoentscheidung, kein abschließend geklärtes Ja oder Nein. reCAPTCHA lädt Google-JavaScript und sendet die IP-Adresse sowie das Verhalten des Besuchers an Google. Das ist eine Verarbeitung, die unter der DSGVO eine Rechtsgrundlage benötigt, und mehrere EU-Behörden (darunter die französische CNIL) haben darauf hingewiesen. Zwei praktische Wege: Binden Sie CAPTCHA in Ihren Einwilligungsmechanismus ein (dafür existiert der displayGDPRConsent-Hook), oder umgehen Sie die Google-Datenübermittlung vollständig mit hCaptcha. Wofür Sie sich auch entscheiden: Laden Sie das CAPTCHA-Skript niemals vor der Einwilligung, wenn Sie es als nicht essenziell behandeln.

Ersetzt CAPTCHA andere Sicherheitsmaßnahmen?

Nein. Es ist eine Schicht. CAPTCHA stoppt automatisierten Formularmissbrauch: gefälschte Konten, Kontakt-Spam, Fluten von Zurücksetzen-E-Mails, Brute-Force-Rauschen. Es stoppt keine verteilten Bots mit rotierenden IPs, keine Traffic-Fluten und niemanden, der bereits am Formular vorbei ist. Kombinieren Sie es mit Bad-Bot- und IP-Blockierung für Traffic, der Ihre Formulare gar nicht erreichen sollte, mit Zwei-Faktor-Authentifizierung und Passwortrichtlinien im Backoffice sowie mit einem Incident-Plan für den Fall, dass doch etwas durchkommt. CAPTCHA auf Registrierung, Kontakt und Anmeldung ist eine solide Schicht eines gehärteten Shops, nicht die Ziellinie.