Card Testing und Credential Stuffing im Onlineshop

Card Testing und Credential Stuffing sind Bot-Angriffe auf Ihren Shop. Beim Card Testing prüfen Bots gestohlene Kartendaten auf Gültigkeit. Dafür zahlen sie Kleinstbeträge oder hinterlegen eine Karte im Kundenkonto. Beim Credential Stuffing probieren sie Login-Paare aus fremden Datenlecks an Ihren Kundenkonten durch. Sie erkennen beide an Spitzen fehlgeschlagener Zahlungen oder Anmeldungen. Wirksam ist erst die Kombination: Regeln des Zahlungsanbieters, Captcha und Zwei-Faktor-Anmeldung im Shop, Rate-Limits am Netzwerkrand. Stand: 5. September 2026.

Für wen dieser Beitrag geschrieben ist: für Betreiber und Teams von Onlineshops. Sie sehen unerklärliche Kleinstbestellungen, Wellen fehlgeschlagener Zahlungen oder Beschwerden über fremde Logins. Und Sie wollen wissen, was dahintersteckt und was zuerst zu tun ist. Eine Sicherheitsprüfung Ihres konkreten Shops ersetzt er nicht.

1. Fünf Begriffe, ein Muster

Im Alltag geraten die Begriffe durcheinander. Sie meinen aber verschiedene Dinge und verlangen verschiedene Gegenmittel. Gemeinsam ist ihnen das Muster: Ein Skript probiert in kurzer Zeit sehr viele Kombinationen durch. Ihr Shop dient dabei als Prüfstand. Der Schaden entsteht, ohne dass Ihr Shop eine Sicherheitslücke haben muss.

Stripe beschreibt Kartentests als „eine Art betrügerischer Aktivität, bei der jemand die Gültigkeit gestohlener Kartendaten zu ermitteln versucht, um sie anschließend für Einkäufe zu verwenden“. Der häufigere Weg ist die Karteneinrichtung: Der Bot hinterlegt eine Karte im Kundenkonto, ohne zu zahlen. Diese Prüfung erscheint laut Stripe „in der Regel nicht auf den Kreditkartenabrechnungen“. Der Karteninhaber bemerkt nichts. Der zweite Weg sind Zahlungen in geringer Höhe. Gültige Karten nutzen die Täter danach für Einkäufe oder verkaufen sie weiter (Quelle: Stripe-Dokumentation zu Kartentests, abgerufen am 5. September 2026, öffnet in neuem Tab).

Credential Stuffing definiert Cloudflare als Angriff, „bei dem Anmeldedaten, die bei einer Datenschutzverletzung bei einem Dienst erbeutet wurden, verwendet werden, um sich bei einem anderen, nicht verwandten Dienst anzumelden“. Die Erfolgsquote liegt „nach vielen Schätzungen“ bei „etwa 0,1 %“. Aus einer Million Datensätze werden so rund tausend Konten. Der Angriff lohnt sich trotzdem. Die gehandelten Listen enthalten Millionen Einträge. Und laut den von Cloudflare zitierten Studien verwenden „schätzungsweise bis zu 85 %“ der Nutzer Passwörter mehrfach (Quelle: Cloudflare Learning Center, abgerufen am 5. September 2026, öffnet in neuem Tab).

Ein starkes Passwort schützt nicht vor Credential Stuffing. „Es spielt keine Rolle, wie stark ein Passwort ist – wenn es für verschiedene Konten verwendet wird, kann Credential Stuffing jedes noch so starke Passwort kompromittieren“, schreibt Cloudflare. Passwortregeln helfen gegen Brute Force und Password Spraying. Gegen geleakte Paare hilft nur ein zweiter Faktor oder der Abgleich mit bekannten Leaks. Und: Das Leck war bei einem anderen Anbieter. Ihr Shop ist Schauplatz, nicht Ursache.

2. Woran Sie den Angriff im Shop erkennen

Beide Angriffe sind laut, wenn man weiß, wohin man schaut. „Oftmals ist der einzige Hinweis auf einen Angriff, den das geschädigte Unternehmen hat, die Zunahme des Gesamtvolumens der Anmeldeversuche“, schreibt Cloudflare zum Credential Stuffing. Beim Card Testing liegen die Signale beim Zahlungsanbieter, nicht im Shop.

Stripe nennt drei Beobachtungen, die auf Kartentests hindeuten:

• „Ein Anstieg fehlgeschlagener oder blockierter Zahlungen“.
• „Ein Anstieg der Anfragen mit 402-Fehlern“ — vor allem mit dem Ergebnis „generic_decline“.
• „Ein Anstieg verdächtiger Zahlungen mit niedrigen Transaktionsbeträgen, oft im Zusammenhang mit unsinnigen Kundennamen und E-Mail-Adressen“.

Der dritte Punkt ist der tückische: Diese Zahlungen sind gelungen. Sie stehen als Bestellung in Ihrer Warenwirtschaft. Erstatten Sie sie nicht vorher, werden sie später angefochten.

Wie sich eine Bot-Welle anfühlt, zeigt ein Fall aus dem JTL-Forum: „sobald wir Werbeanzeigen bei Meta schalten, massiven Botspam im Shop“. Die Bots versuchten, Kundenkonten anzulegen, „was sie durch Captcha nicht können“. Den Shop bremsten sie trotzdem massiv aus. Nach zehn Minuten Anzeigenlaufzeit standen „1000 Bots im Shop, kein echter Besucher“. Der Auslöser war der Kampagnenstart. Wer Budget einschaltet, macht seinen Shop für Skripte sichtbar (Quelle: JTL-Forum, Thread „AdFraud Traffic durch Bots“, abgerufen am 5. September 2026, öffnet in neuem Tab).

Eine gelungene Kontoübernahme melden meist Ihre Kunden — wenn der Shop sie informiert. JTL-Shop bringt laut JTL-Guide ab Version 5.8 passende E-Mail-Vorlagen mit. Der Shop verschickt sie bei einer Passwort- oder E-Mail-Änderung, mit Datum, Uhrzeit und IP-Adresse. OWASP empfiehlt auch eine Nachricht, wenn ein Login mit korrektem Passwort am zweiten Faktor scheitert. Dann ist das Passwort bereits in fremden Händen.

3. Was ein Angriff kostet — laut Stripe

Wir nennen keine Schadenssummen. Belastbare Zahlen für den einzelnen Shop gibt es nicht, und wir erfinden keine. Belegbar ist die Kostenstruktur. Stripe listet sechs Folgen von Kartentests auf, „von denen sich einige mit der Zeit verschlechtern, wenn die Kartentests fortgesetzt werden“.

• Angefochtene Zahlungen: Erfolgreiche Testzahlungen fallen den Karteninhabern auf. Sie melden sie als Betrug. Frühe Betrugswarnungen und Anfechtungen kosten Zeit und Geld.
• Höhere Ablehnungsquoten: Viele Ablehnungen schaden dem Ruf bei Kartenausstellern und Kartennetzwerken. Laut Stripe steigt so die Ablehnungsquote legitimer Zahlungen, „selbst wenn keine Kartentests mehr stattfinden“.
• Zusätzliche Gebühren: Autorisierungsgebühren bei benutzerdefinierten Preisplänen und Anfechtungsgebühren. Und das für Zahlungen, die nie Umsatz waren.
• Belastung der Infrastruktur: Zahlreiche Netzwerkanfragen können laut Stripe Ihre Systeme überlasten. Das unterbricht legitime Aktivitäten.
• Kartenüberwachungsprogramme: Häufen sich frühe Betrugswarnungen oder Anfechtungen, können die Kartennetzwerke Sie in ein Überwachungsprogramm aufnehmen.
• Verzerrte Daten: Einnahmen aus Kartentests sehen in Ihren Zahlen wie neue Kunden aus. Die echte Entwicklung Ihres Geschäfts wird unlesbar.

Der zweite Punkt ist der teuerste, weil er unsichtbar bleibt. Echte Kunden mit gültiger Karte werden abgelehnt. Sie brechen ab und kommen oft nicht zurück. Diese Umsätze stehen in keiner Betrugsstatistik. Stripe warnt, ein hoher Anteil abgelehnter Zahlungen könne dem Ruf schaden, „wodurch alle Ihre Transaktionen riskanter erscheinen“. Wer früh stoppt, schützt die Zahlungsakzeptanz der kommenden Monate, nicht nur die Gebührenabrechnung.

Bei Credential Stuffing beginnt der Schaden bei Ihren Kunden. Cloudflare nennt als Folgen einer Kontoübernahme: Diebstahl von Kreditkartennummern und personenbezogenen Daten, Weiterverkauf des Zugangs, Reputationsschäden und mögliche behördliche Strafen. Im Shop-Alltag kommt mehr dazu: Bestellungen mit gespeicherten Zahlarten, verbrauchte Gutscheine und Support-Zeit für das Zurücksetzen von Passwörtern. Ob ein Vorfall meldepflichtig ist, klären Sie am selben Tag mit Ihrer oder Ihrem Datenschutzbeauftragten.

4. Sofortmaßnahmen: die ersten Stunden

Stripe fasst die Reaktion in vier Schritten zusammen: Aktivität identifizieren, betrügerische Zahlungen erstatten, Gegenmaßnahmen ergänzen, Wirkung überwachen. Wir haben die Liste aus Händlersicht ausgeschrieben und um den Login ergänzt. Die Reihenfolge ist die, die in unseren Projekten funktioniert.

1. Zeitraum und Einstiegspunkt eingrenzen. Seit wann läuft es? Über welche URL: Checkout, Registrierung oder Login? Welche Zahlart, welche Herkunft nach Land, User-Agent und IP-Bereichen? Server-Logs und das Dashboard des Zahlungsanbieters liefern die Antwort. Ohne Eingrenzung treffen alle weiteren Maßnahmen auch echte Kunden.
2. Erfolgreiche Testzahlungen erstatten. Stripe empfiehlt die „Rückerstattung betrügerischer Zahlungen, um Anfechtungen zu vermeiden“. Eine Anfechtung kostet Gebühr, Zeit und Betrugsquote. Eine Erstattung kostet nur den Klick. Die Aufträge stornieren Sie danach in der Warenwirtschaft. Abschnitt 6 zeigt, wie.
3. Zahlungsanbieter informieren, Schlüssel prüfen. Kartentester können laut Stripe Ihren veröffentlichbaren Schlüssel für Massenversuche nutzen. Der Geheimschlüssel darf nie öffentlich sein. Wurde er offengelegt, tauschen Sie ihn aus.
4. Captcha an Zahlung, Registrierung und Login scharf stellen. Stripe verlangt die Prüfung „bei allen Anfragen, die Kartenvalidierungen oder Zahlungen mit Stripe ermöglichen“ — und zwar serverseitig. Bei Lösungen mit Punktzahl passen Sie den Schwellenwert an. Sonst wechseln Sie von unsichtbar auf sichtbar.
5. Rate-Limit setzen. Stripes Beispiel: „die Anzahl neuer Kundinnen/Kunden zu begrenzen, die an einem Tag über eine einzige IP-Adresse erstellt werden können“. Am schnellsten greift eine Regel am Netzwerkrand auf Login- und Checkout-URL. Mehr dazu in Abschnitt 5.
6. Zugang zum Zahlungsformular verengen. Je einfacher der Weg zur Kasse, „z. B. über den Bezahlvorgang als Gast“, desto einfacher der Kartentest, schreibt Stripe. Kurzfristig hilft eine Anmeldepflicht vor der Zahlung. Auch CSRF-Token wirken. Dauerhaft ist das eine Abwägung, denn ein Gast-Checkout senkt Warenkorbabbrüche.
7. Keine blinden Wiederholungsversuche. Automatische Zahlungswiederholungen können laut Stripe „wie Kartentests aussehen“. Karten, die Täter eingerichtet haben, dürfen Sie nicht erneut belasten. „Das wäre eine Wiederholung des ursprünglichen Angriffs“, schreibt Stripe. Prüfen Sie Abo- und Mahnläufe.
8. Konten und Aufträge bereinigen. Bei Credential Stuffing setzen Sie die Passwörter der betroffenen Konten zurück. Beenden Sie aktive Sitzungen und informieren Sie die Kunden. Fake-Aufträge stornieren Sie in der Warenwirtschaft mit einem eigenen Stornogrund. So bleiben sie auswertbar.
9. Überwachen. Stripe verlangt, die Integration zu überwachen, „um sicherzustellen, dass Ihre Gegenmaßnahmen wirksam sind“. OWASP will für jede Maßnahme Kennzahlen. Angriffe kommen in Wellen.

5. Schutz in drei Schichten

Eine Maßnahme allein reicht nicht. Filter, „die auf einer einzigen Heuristik wie IP-Adressen basieren“, reichten „in der Regel nicht aus“, schreibt Stripe. OWASP nennt das Prinzip Defense in Depth: Jede Schicht rechnet damit, dass eine andere ausfällt. Für einen Shop sind es drei Schichten. Jede hat einen blinden Fleck, den die nächste abdeckt.

Schicht 1: der Zahlungsanbieter

Hier entscheidet sich, ob ein Kartentest überhaupt eine Antwort bekommt. Stripe empfiehlt die aktuellen Bezahlbausteine. Dort sind „Begrenzer, KI-Modelle, Auslöser für CAPTCHA, laufende Überprüfungen und mehr“ eingebaut. Der Erfolg hängt an den Daten, die Ihre Integration mitliefert. Die höchste Wirkung haben laut Stripe vier davon: IP-Adresse, Kunden-E-Mail, Kundenname, Rechnungsadresse. Dazu kommen eigene Regeln — bei Stripe über Radar, bei anderen Anbietern unter anderem Namen. Stripes Beispiele: Karten je Konto, Kunden je IP-Adresse, Käufe desselben Produkts, bestimmte User-Agents, CVC-Prüfungen. Für Plugin-Nutzer gilt Stripes Hinweis, dass „in der Regel Änderungen auf Code-Ebene erforderlich“ sind. Die Dokumentation gehört also zum Entwickler oder Plugin-Anbieter.

3-D Secure ist die zweite Verteidigung. Stripe beschreibt es als „ein Authentifizierungsprotokoll, das Kartentransaktionen eine zusätzliche Sicherheitsebene hinzufügt“. Es prüft, „ob die Person, die einen Kauf tätigt, der/die legitime Karteninhaber/in ist“. Das geschieht per Passwort, Einmalcode oder Biometrie bei der ausstellenden Bank. Im Europäischen Wirtschaftsraum verlangt die starke Kundenauthentifizierung nach PSD2 laut Stripe „unter Umständen den Einsatz von 3DS für Kartenzahlungen“. Ein Kartentester ohne die Karte scheitert an dieser Abfrage. Welche Anbieter das wie umsetzen, ordnet unser Beitrag zur Wahl des Zahlungsdienstleisters ein.

Schicht 2: der Shop

Für den Login gibt OWASP eine klare Rangfolge. Die Mehrfaktor-Authentifizierung (MFA) ist „by far the best defense against the majority of password-related attacks“. OWASP verweist dabei auf eine Microsoft-Analyse: Demnach hätte MFA 99,9 Prozent der Kontokompromittierungen verhindert. Das BSI rät, den zweiten Faktor zu nutzen, „sobald ein Online-Dienst dies ermöglicht“, und nennt Online-Shopping ausdrücklich. Damit er Kunden nicht vergrault, empfiehlt OWASP das Step-up-Prinzip: Der Shop verlangt den zweiten Faktor nur bei Auffälligkeiten. Dazu zählen ein neues Gerät oder eine neue IP-Adresse und ein untypisches Land. Verdächtig ist auch eine Adresse, die bereits mehrere Konten probiert hat, oder ein Anmeldemuster, das nach Skript aussieht. Einen Schritt weiter geht die Anmeldung per Passkey. Sie kennt kein Passwort mehr und lässt sich deshalb aus keinem fremden Leck übernehmen. Mehr dazu in unserem Beitrag zu Passkeys im Unternehmen.

Das Captcha hat eine ehrliche Einschränkung. OWASP nennt es „not perfect“, denn Dienste lösen Captchas „with a reasonably high success rate“. Beobachten Sie die Löserate. Verlangen Sie das Rätsel bevorzugt bei verdächtigen Anmeldungen. Zuverlässig stoppt es einfache Skripte ohne Browser. Eine JavaScript-Pflicht schränkt laut OWASP die Barrierefreiheit ein. Bei der Passwort-Hygiene setzt der Shop nur die Länge durch. Das BSI empfiehlt ein Passwort „immer nur für einen Zugang“ und einen Passwortmanager. Ob ein Kunde sein Passwort mehrfach nutzt, sieht kein Shop. Deshalb empfehlen OWASP und Cloudflare den Abgleich neuer Passwörter mit Leak-Listen wie Pwned Passwords. Laut Cloudflare ist auch der „nicht narrensicher“. Mit dem Passwortmanager im Team beginnt auch unser Leitfaden zur IT-Sicherheit im Mittelstand.

Schicht 3: der Netzwerkrand

Die JTL-Community bringt den Grund für diese Schicht auf den Punkt: „Bots blockt man in der Regel auf Server-Ebene, nicht auf App-Ebene. Auf App-Ebene ists quasi schon zu spät, da gehen zu viele Ressourcen schon verloren.“ Ein Captcha-Plugin weist den Bot ab, nachdem PHP und Datenbank die Anfrage verarbeitet haben. Sperren in der .htaccess-Datei werden „nach jedem Update von JTL Shop“ überschrieben. Dauerhafte Regeln gehören deshalb vor den Server: in eine Web Application Firewall oder ein Netzwerk wie Cloudflare.

Rate-Limits sind dort das erste Werkzeug. Cloudflare definiert sie als Regeln, die „rate limits for requests matching an expression“ festlegen, samt der Aktion beim Erreichen. Das Beispiel der Dokumentation: „to protect a login endpoint from brute-force attacks“. Drei Parameter: Zeitraum, Anfragen je Zeitraum, Sperrdauer. Der Free-Plan bietet eine Regel mit zehn Sekunden Zählfenster. Pro bietet zwei Regeln mit Fenstern bis zu einer Minute, Business fünf bis zu zehn Minuten (Stand: 5. September 2026). Mit dem Free-Plan schützen Sie also genau eine URL: Login oder Checkout. Ehrlich dazu: Die Regeln seien „not designed to allow a precise number of requests to reach your origin server“.

Bot Fight Mode ist laut Cloudflare „a simple, free product“. Anfragen, die bekannten Bot-Mustern entsprechen, bekommen rechenintensive Aufgaben. Der Bot zahlt mit Rechenzeit. Der Haken für Shops: Er „cannot be customized, adjusted, or reconfigured via WAF custom rules“. Und er kann API- oder App-Traffic treffen. Genau das sind der JTL-Wawi-Abgleich und die Server-Aufrufe Ihres Zahlungsanbieters. Ausnahmen brauchen eine IP-Zugriffsregel, die vor dem Filter greift. Oder den Super Bot Fight Mode ab dem Pro-Plan mit Skip-Regeln.

Turnstile ersetzt das Captcha-Rätsel an Ihren Formularen. Cloudflare nennt es „smart CAPTCHA alternative“. Es lässt sich in jede Website einbetten, „without sending traffic through Cloudflare“. Und es arbeitet „without showing visitors a CAPTCHA“: Im Hintergrund laufen kleine Rechen- und Browserprüfungen. Laut Cloudflare ist es WCAG 2.2 AA konform und greift nicht auf Formulareingaben zu. Kostenlos ist es bis 20 Widgets mit je zehn Hostnamen. Unsere Service-Seite Cloudflare für JTL-Shop beschreibt, wie sich Rate-Limits, Bot-Filter und Turnstile zu einem Regelwerk zusammensetzen. Und zwar so, dass Wawi-Abgleich und Zahlungs-Webhooks weiterlaufen.

6. JTL-Shop und JTL-Wawi in der Praxis

Die drei Schichten gibt es in jedem Shopsystem. Weil viele unserer Kunden mit JTL arbeiten, zeigen wir die konkreten Stellen für JTL-Shop 5 und JTL-Wawi — nach JTL-Guide, Stand 5. September 2026.

Formulare: Captcha als Plugin

In JTL-Shop 5 ist Google reCAPTCHA kein fester Bestandteil mehr. Es steht laut JTL-Guide „als Plugin im JTL-Extension Store zur Verfügung“, kostenfrei als „JTL Google reCaptcha v2“. Voraussetzung ist ein Google-Konto für die Schlüssel. Sie wählen zwischen sichtbarem Widget und unsichtbarer Prüfung. Den Schutz aktivieren Sie je Formular. Der Guide nennt „das Kontaktformular, das Formular für Fragen zum Artikel oder die Passwort-vergessen-Funktion“. Gerade die letzte wird gern vergessen. Für Credential Stuffing ist sie ein zweiter Eingang. Wer Formulareingaben nicht über Google prüfen lassen möchte: Turnstile binden wir in Kundenprojekten per Plugin ein. Welche Erweiterungen sich bewährt haben, sammelt unsere Übersicht der JTL-Shop-5-Plugins.

Kundenkonten und Backend härten

JTL-Shop bringt laut Guide eine Zwei-Faktor-Authentifizierung „für das Frontend und für das Backend“ mit. Sie gilt für Kundenkonten wie für Admin-Zugänge. Kundenpasswörter müssen mindestens 8 Zeichen lang sein. JTL empfiehlt 12. Mindestlänge und Sperre alter Passwörter stellen Sie unter Darstellung, Standardansichten, Registrierung ein. Ab JTL-Shop 5.8 gibt es Benachrichtigungen bei Passwort- und E-Mail-Änderung. Sie aktivieren sie unter Administration, E-Mail, Vorlagen. Dieser Baustein macht Kontoübernahmen für Ihre Kunden sichtbar. Für das Backend empfiehlt der Guide lange, nur einmal verwendete Admin-Passwörter und eine regelmäßige Prüfung der Backend-Benutzer. Dazu eine zusätzliche Hürde vor /admin/: per .htpasswd oder über einen nicht erratbaren Pfad. Das „reduziert automatisierte Zugriffsversuche deutlich“.

Fake-Aufträge in JTL-Wawi aussortieren

Erfolgreiche Testzahlungen laufen als Aufträge in die Warenwirtschaft. Sie erkennen sie an Kleinstbeträgen, unsinnigen Namen und Serien innerhalb weniger Minuten. Die Reihenfolge: erst die Zahlung beim Zahlungsanbieter erstatten, dann den Auftrag stornieren. Laut JTL-Guide geht das unter Verkauf, Aufträge über die Schaltfläche Storno. Dort wählen Sie Stornieren und geben einen Stornogrund und einen Kommentar an. Der Auftrag wandert nach Aufträge, Storniert. Ein wiederkehrender Kommentar wie „Kartentest“ zahlt sich aus. Denn so werten Sie den Angriff später aus oder belegen ihn dem Zahlungsanbieter.

Die Voraussetzungen setzen Grenzen. Stornieren geht laut Guide nur, solange kein Lieferschein existiert. Der Auftrag darf auf keiner Pickliste liegen, und es darf keine Rechnung existieren. „Sie können bereits versendete Aufträge nicht stornieren“, stellt der Guide klar. Die Erkennung muss also vor dem Versand greifen. Ein Auftragsfilter auf Kleinstbeträge und Neukunden ist in unseren Projekten der einfachste Frühwarner. Ist der Auftrag bezahlt und die Zahlung über einen angebundenen Zahlungsanbieter abgeholt? Dann erzeugen Sie beim Storno gleich eine Ausgangszahlung. Solche Prüfungen in Ihren Abläufen zu verankern, gehört zu unserer JTL-Wawi-Beratung.

Abgleich und Webhooks hinter dem Bot-Filter

Wer den Netzwerkrand einschaltet, muss den Wawi-Abgleich mitdenken. Im JTL-Forum berichtete ein Betreiber: Seit dem Wechsel zu Cloudflare laufe der Worker nicht mehr. Ursache war der Super Bot Fight Mode. Die bestätigte Lösung: eine IP-Zugriffsregel mit der Aktion Zulassen für den Server, auf dem der Worker läuft. „Mein Test soeben hat ergeben, dass der Worker wie erwartet durch den Super Modus durch kommt solange eine entsprechende Regel für den Server existiert“, meldete er zurück. Der Rat aus demselben Thread gilt für jede Schutzregel: „immer nur ein oder zwei Filter oder Blockierungen einstellen und danach prüfen ob noch alles läuft“ (Quelle: JTL-Forum, Thread „Cloudflare und JTL Shop“, abgerufen am 5. September 2026, öffnet in neuem Tab). Dasselbe gilt für die Server-Aufrufe der Zahlungsanbieter. Fängt der Bot-Filter sie ab, bleiben Bestellungen unbezahlt stehen. In unseren Projekten legen wir vor dem Scharfschalten Ausnahmen für Abgleich und Zahlungs-Webhooks an. Danach testen wir jede Zahlart durch. Unsere JTL-Shop-Beratung betrachtet Sicherheit und Zahlungsanbindung deshalb gemeinsam.

7. Fazit: Schauplatz, nicht Ursache — aber Ihre Verantwortung

Card Testing und Credential Stuffing nutzen Ihren Shop als Prüfstand für Daten, die anderswo gestohlen wurden. Sie brauchen keine Lücke, nur einen erreichbaren Login und Checkout. Deshalb hilft weder ein starkes Passwort allein noch ein Captcha allein noch eine IP-Sperre allein. Es hilft die Kombination: Regeln und 3-D Secure beim Zahlungsanbieter. Zwei-Faktor-Anmeldung, Captcha und Benachrichtigungen im Shop. Rate-Limits und Bot-Filter am Netzwerkrand.

Unser Rat aus Projekten: Beginnen Sie mit dem, was nichts kostet und sofort wirkt. Das sind die Zwei-Faktor-Anmeldung in JTL-Shop, ein Captcha auch an der Passwort-vergessen-Funktion, eine Rate-Limit-Regel am Login oder Checkout und die Benachrichtigungs-Mails ab JTL-Shop 5.8. Legen Sie fest, wer das Dashboard des Zahlungsanbieters im Blick hat. Vereinbaren Sie die Reihenfolge Erstatten, dann Stornieren, bevor der erste Angriff kommt. Und prüfen Sie jede neue Schutzregel gegen Wawi-Abgleich und Zahlungs-Webhooks. Sonst schützt sie den Shop vor seinen eigenen Bestellungen.

Alle Angaben zu Stripe, Cloudflare, OWASP, BSI und JTL stammen aus den jeweiligen Dokumentationen, abgerufen am 5. September 2026. Funktionsumfang und Plan-Grenzen ändern sich. Verbindlich ist die aktuelle Dokumentation Ihres Anbieters. Die vollständige Quellenliste steht am Ende des Beitrags.

Hinweis: Dieser Beitrag gibt den Stand vom 5. September 2026 wieder. Er ordnet Angriffsmuster und Schutzmaßnahmen allgemein ein. Er ersetzt weder eine Sicherheitsprüfung Ihres Shops noch eine Rechtsberatung, etwa zur Frage, ob ein Vorfall meldepflichtig ist. Klären Sie das mit Ihrer oder Ihrem Datenschutzbeauftragten. Bei nachweisbarem Schaden wenden Sie sich an die Polizei.

8. Häufige Fragen zu Card Testing und Credential Stuffing

Was ist der Unterschied zwischen Credential Stuffing und Password Spraying?

Beide Angriffe zielen auf den Login, arbeiten aber spiegelverkehrt. Credential Stuffing probiert vollständige Paare aus Benutzername und Passwort durch. Sie stammen aus dem Datenleck eines anderen Dienstes. Password Spraying testet ein einzelnes, schwaches Passwort gegen sehr viele verschiedene Konten. OWASP führt beide neben dem klassischen Brute-Force-Angriff. Dabei laufen viele Passwörter gegen ein einzelnes Konto.

Wie verhindere ich Credential Stuffing in meinem Onlineshop?

Am wirksamsten ist laut OWASP eine Zwei-Faktor-Anmeldung. JTL-Shop bietet sie für Kundenkonten und Backend an. Dazu kommen ein Captcha am Login, Rate-Limits je IP-Adresse am Netzwerkrand, ein Abgleich neuer Passwörter gegen bekannte Leak-Listen und Benachrichtigungen bei Passwortänderungen. Keine dieser Maßnahmen allein reicht aus. Erst die Kombination macht den Angriff für Bots unwirtschaftlich.

Was ist ein credential-based attack?

Der Sammelbegriff meint Angriffe, die mit Zugangsdaten arbeiten statt mit Sicherheitslücken. Dazu zählen Credential Stuffing mit geleakten Login-Paaren, Password Spraying mit einem häufigen Passwort und Brute Force mit vielen Passwörtern gegen ein Konto. Auch Phishing gehört dazu, weil es Zugangsdaten direkt abgreift. Gelingt einer davon, spricht man von einer Kontoübernahme, englisch Account Takeover. Der Shop braucht dafür keine Schwachstelle.

Woran erkenne ich Card Testing in meinem Shop?

Stripe nennt drei Signale: einen Anstieg fehlgeschlagener oder blockierter Zahlungen, mehr Anfragen mit dem Fehlercode 402 und eine Häufung verdächtiger Zahlungen mit sehr kleinen Beträgen. Dazu kommen oft unsinnige Kundennamen und E-Mail-Adressen. Im Shop fallen zusätzlich viele Registrierungen in kurzer Zeit auf. Prüfen Sie bei Verdacht zuerst das Dashboard Ihres Zahlungsanbieters, dann die Auftragsliste in der Warenwirtschaft.

Reicht ein Captcha gegen Card Testing aus?

Nein, aber es gehört dazu. Stripe empfiehlt ein Captcha an jedem Endpunkt, der Karten speichert oder Zahlungen auslöst. Die Prüfung muss serverseitig laufen. OWASP weist zugleich darauf hin, dass es Dienste gibt, die Captchas mit hoher Erfolgsquote lösen. Deshalb kombinieren Sie es mit Rate-Limits, Regeln des Zahlungsanbieters und einer Anmeldepflicht vor der Zahlung.

Was mache ich mit Fake-Bestellungen in JTL-Wawi?

Erstatten Sie zuerst die Zahlung beim Zahlungsanbieter. Stripe empfiehlt das, um Anfechtungen zu vermeiden. Danach stornieren Sie den Auftrag in JTL-Wawi über Verkauf, Aufträge und die Schaltfläche Storno mit einem Stornogrund. Das geht laut JTL-Guide nur, solange kein Lieferschein, keine Pickliste und keine Rechnung existieren. Bereits versendete Aufträge lassen sich nicht mehr stornieren.

Ist Cloudflare Turnstile kostenlos, und muss der Shop dafür hinter Cloudflare laufen?

Turnstile lässt sich laut Cloudflare-Dokumentation in jede Website einbetten, ohne den Datenverkehr durch Cloudflare zu leiten. Besuchern zeigt es in der Regel kein Rätsel. Kostenlos sind bis zu 20 Widgets mit je zehn Hostnamen. Für Rate-Limits und Bot Fight Mode muss der Shop dagegen hinter Cloudflare laufen. Diese Funktionen arbeiten am Netzwerkrand.

9. Quellen & weiterführende Dokumentation

Alle Angaben in diesem Beitrag stützen sich auf die folgenden Quellen. Alle wurden am 5. September 2026 abgerufen und im Text gegengelesen. Externe Quellen öffnen in einem neuen Tab.

• Stripe — Schützen Sie sich vor Kartentests — Definition und weitere Begriffe. Die beiden Wege Karteneinrichtung und Kleinstzahlung. Sechs Folgen von Kartentests. Erkennungssignale inklusive 402-Fehler. Checkliste für aktive Kartentests. Empfohlene Integration und Datenpunkte mit höchster Wirkung. Captcha, Zugriffsbeschränkung, Ratenbegrenzung, Radar-Regeln. Umgang mit Wiederholungsversuchen und Schlüsseln.
• Stripe — 3D Secure-Authentifizierung — Definition von 3D Secure als zusätzliche Sicherheitsebene. Prüfung des legitimen Karteninhabers durch die ausstellende Bank. Zusammenhang mit der starken Kundenauthentifizierung im Europäischen Wirtschaftsraum.
• OWASP — Credential Stuffing Prevention Cheat Sheet — Abgrenzung von Brute Force, Credential Stuffing und Password Spraying. Mehrfaktor-Authentifizierung als wirksamste Abwehr, mit Step-up-Auslösern. Defense in Depth. Grenzen von Captcha und IP-Sperren. Abgleich mit Leak-Listen und Benachrichtigung der Nutzer. Barrierefreiheits-Vorbehalt bei JavaScript-Pflicht.
• Cloudflare Learning Center — Was bedeutet Credential Stuffing? — Definition und geschätzte Erfolgsquote von etwa 0,1 Prozent. Passwort-Wiederverwendung als Ursache. Verteilung der Versuche über Geräte und IP-Adressen. Anstieg der Anmeldeversuche als oft einziger Hinweis. Unterschied zum Brute-Force-Angriff. Gegenmaßnahmen.
• Cloudflare Learning Center — Was ist eine Kontoübernahme? — Definition der Kontoübernahme und Wege dorthin. Folgen wie Datendiebstahl und Weiterverkauf des Zugangs. Prävention von Passwortrichtlinien bis Mehrfaktor-Authentifizierung.
• Cloudflare Docs — Turnstile — Turnstile als Captcha-Alternative. Einbettung ohne Umleitung des Datenverkehrs über Cloudflare. Funktionsweise ohne sichtbares Rätsel, Widget-Typen. WCAG-2.2-AA-Konformität und keine Verarbeitung von Formulareingaben.
• Cloudflare Docs — Turnstile plans — Kostenloser Plan mit bis zu 20 Widgets je Konto und zehn Hostnamen je Widget. Höhere Grenzen nur im Enterprise-Plan.
• Cloudflare Docs — Rate limiting rules — Definition der Rate-Limit-Regeln. Parameter Zeitraum, Anfragen je Zeitraum und Sperrdauer. Beispiel Login-Endpunkt gegen Brute Force. Hinweis auf die Verzögerung der Zähler.
• Cloudflare Docs — Bot Fight Mode — Kostenloser Bot-Filter mit rechenintensiven Challenges. Keine Anpassung über eigene Firewall-Regeln. Mögliche Auswirkungen auf API- und App-Traffic. Ausnahmen nur über Super Bot Fight Mode oder vorrangig greifende IP-Zugriffsregeln.
• JTL-Guide — Spamschutz mit Google reCAPTCHA einrichten — reCAPTCHA als kostenfreies Plugin im JTL-Extension Store. Voraussetzungen, Widget oder unsichtbare Integration. Aktivierung je Formular, Testfunktion.
• JTL-Guide — Sicherheit in JTL-Shop — Zwei-Faktor-Authentifizierung für Frontend und Backend. Mindestpasswortlänge, Passwortgütebalken und Sperre alter Passwörter. Ablauf des Passwort-vergessen-Links. Benachrichtigungen bei Passwort- und E-Mail-Änderung ab JTL-Shop 5.8. Absicherung des Admin-Bereichs.
• JTL-Guide — Aufträge stornieren — Voraussetzungen für die Stornierung und Ausschluss bereits versendeter Aufträge. Weg über Verkauf und Aufträge mit Stornogrund. Ordner Storniert. Ausgangszahlung bei bereits bezahlten Aufträgen.
• JTL-Forum — AdFraud Traffic durch Bots — Praxisfall mit Bot-Welle nach Kampagnenstart, Registrierungsversuchen und verlangsamtem Shop. Einordnung, dass Bots auf Server-Ebene statt in der Anwendung zu blocken sind. Hinweis auf überschriebene .htaccess nach Shop-Updates.
• JTL-Forum — Cloudflare und JTL Shop — Ausfall des JTL-Wawi-Workers unter Super Bot Fight Mode. Lösung über eine IP-Zugriffsregel für den Worker-Server. Rat, Filter schrittweise zu aktivieren und den Abgleich danach zu prüfen.
• BSI — Sichere Passwörter erstellen — Werkzeuge der Angreifer. Grundsatz eines Passworts je Zugang. Längen- und Komplexitätsempfehlungen, Passwortmanager.
• BSI — Zwei-Faktor-Authentisierung — Funktionsweise des zweiten Faktors und gängige Verfahren. Empfehlung, den zweiten Faktor überall zu nutzen, wo ein Dienst ihn anbietet. Ausdrücklich auch beim Online-Shopping.