Fünf Formulare, fünf Entscheidungen.
Onlineshop.
Ein Shop hat mehr angreifbare Formulare als jede andere Art von Seite. Und an genau einem davon darf auf keinen Fall etwas im Weg stehen.
Stand: August 2026
Welche Formulare in einem Shop werden automatisiert bearbeitet?
Fünf, und sie brauchen unterschiedliche Antworten.
Gutscheinfeld, Kontoanlage, Anmeldung, Bewertung und Kasse werden aus verschiedenen Gründen und mit verschiedenen Mitteln bearbeitet. Wer alle fünf gleich behandelt, stellt entweder der Kasse eine Aufgabe in den Weg oder lässt das Gutscheinfeld offen.
- GutscheinfeldKurze Codes nach festem Muster werden erzeugt und der Reihe nach eingelöst.
- KontoanlageKonten für Neukundenrabatte, Bewertungen und Empfehlungsprämien.
- AnmeldungErbeutete Zugangsdaten werden an fremden Konten durchprobiert.
- BewertungenBewertungen ohne Kauf, in beide Richtungen.
- KasseWiederholte Bestellversuche aus derselben Sitzung. Die Zahlungsfreigabe selbst liegt dahinter und außerhalb.
Jedes davon lässt sich als eigene Seite im Dashboard führen, mit eigenem Modus und eigenen Werten.
- Gutscheincodes
- Ein Code nach festem Muster ist kurz genug, um ihn zu erzeugen und auszuprobieren. Das Formular sagt bei jedem Versuch, ob der Code gilt.
- Kontoanlage
- Konten für Neukundenrabatte, Empfehlungsprämien und Bewertungen. Angelegt werden sie aus einer Liste, benutzt werden sie später.
- Anmeldung
- Erbeutete Zugangsdaten werden an fremden Konten durchprobiert. Für diesen Fall gibt es eine eigene Seite.
- Bewertungen
- Bewertungen aus Konten, die zu diesem Zweck angelegt wurden. Der Schaden liegt in der Glaubwürdigkeit Ihres ganzen Sortiments.
- Nicht dabei
- Preisabgriff, das Aufkaufen knapper Ware und das Blockieren von Bestand laufen nicht über ein Formular mit Absendeknopf. Eine Formularprüfung bekommt sie nicht zu sehen.
Was kostet das einen Händler?
Marge, Bestand und Glaubwürdigkeit.
Ein erratener Gutscheincode ist ein Rabatt, den niemand beschlossen hat. Reservierte und nie bezahlte Ware fehlt im Verkauf. Bewertungen aus erfundenen Konten kosten Vertrauen. Keiner dieser drei Posten taucht in einem Protokoll als Angriff auf.
Das OWASP Automated Threat Handbook trennt die Fälle sauber. Das Durchprobieren von Codes läuft dort unter OAT-002 Token Cracking, der automatisierte Aufkauf knapper Ware unter OAT-005 Scalping, das Blockieren von Bestand unter OAT-021 Denial of Inventory und das Abgreifen von Preisen unter OAT-011 Scraping. Der bekannteste Fall, OAT-001 Carding, ist dort beschrieben als „Multiple payment authorisation attempts to verify the validity of bulk stolen payment card data“. Er ist zugleich der Fall, bei dem eine Formularprüfung am wenigsten ausrichtet. Dazu weiter unten mehr.
- Marge
- Ein erratener Gutscheincode ist ein Rabatt, den Sie nie gewährt haben. Er fällt oft erst in der Abrechnung auf.
- Rechenlast
- Wiederholte Einlöseversuche laufen durch Ihren teuersten Code: Preisberechnung, Bestandsprüfung, Rabattlogik.
- Freikontingente
- Jedes angelegte Konto verbraucht Neukundenrabatte und Empfehlungsprämien, die für echte Kunden gedacht waren.
- Ruf
- Bewertungen, die niemand geschrieben hat, kosten Vertrauen bei Kunden und bei Marktplätzen.
- Aufräumen
- Unechte Konten und Bewertungen müssen einzeln angesehen und einzeln entfernt werden. Diese Entscheidung ist im Nachhinein teuer.
Welcher Modus gehört ans Gutscheinfeld und welcher an die Kasse?
Ans Gutscheinfeld die Kachelauswahl, an die Kasse nichts Sichtbares.
Das Gutscheinfeld gibt bei jedem Versuch eine eindeutige Antwort und wird deshalb durchprobiert. Dort ist eine sichtbare Aufgabe vertretbar. An der Kasse steht ein Kunde mit gefülltem Warenkorb, und jede zusätzliche Handlung dort kostet Umsatz.
Gutscheinfeld
Kachelauswahl
- Sichtbare Aufgabe vor dem Einlösen
- Enges Ratelimit je Besucher
- Einmal je Bestellung, nicht je Seitenaufruf
- Drei Schwierigkeitsgrade
Kasse
Unsichtbar
- Kein sichtbares Element im Bestellweg
- Ratelimit und Rechenaufgabe bleiben aktiv
- Keine zusätzliche Handlung für den Kunden
- Ein Abbruch im Bestellweg ist teurer als jeder Bot
Beide Seiten laufen über dieselben Prüfungen. Unterschiedlich ist nur, was ein Kunde davon sieht.
- Widget-ModusKachelauswahl
- Schwierigkeitmittel
- Rechenaufgabean
- Time-to-Pass2 s
- Ratelimit je Besucher3 / 10 min
Beispielhafte Werte. Jede Seite hat ihren eigenen Sitekey und ihre eigenen Werte.
Echte Aufnahme des laufenden Widgets, aufgenommen gegen die Produktivumgebung.
- Gutscheinfeld
- Hier ist eine sichtbare Aufgabe vertretbar. Ein Gutschein wird einmal je Bestellung eingelöst, und wer einen gültigen Code hat, gibt ihn genau einmal ein.
- Kasse
- Dort gehört keine zusätzliche Hürde hin. Ein Kunde mit gefülltem Warenkorb ist das Letzte, was man aufhalten will. Unsichtbarer Modus, dazu ein Ratelimit.
- Anmeldung
- Unsichtbar, dazu Ratelimit und Zugriffsregeln. Zu erbeuteten Zugangsdaten Mehr dazu ›
- Regeln je Seite
- Zur Zugriffskontrolle
Wo hört eine Formularprüfung auf?
An der Schnittstelle zu Ihrem Zahlungsdienstleister.
ByeBot sitzt in Formularen Ihrer Seite. Wer Kartendaten direkt gegen die Schnittstelle eines Zahlungsdienstleisters testet, kommt an Ihrem Formular gar nicht vorbei. Gegen diesen Fall wirken die Regeln Ihres Zahlungsdienstleisters, nicht diese Prüfung.
- Codes nach Muster
- Kontoanlage aus Liste
- Bewertung ohne Kauf
- Echter Kunde
ByeBot-Prüfung
im Formular
Bestanden
- Ihr Shop verarbeitet den Vorgang
- Die Zahlung läuft wie bisher
Nicht bestanden
- Kein gültiges Token
- Kein Einlösen, keine Reservierung
- Erscheint als blockiert
Vereinfachte Darstellung. Die Zahlungsfreigabe selbst liegt außerhalb dessen, was eine Formularprüfung sieht.
<script src="https://challenge.byebot.de/ray/widget.js" defer></script>
<form method="post" action="/warenkorb/gutschein">
<input name="code" autocomplete="off" required />
<div class="captcha-widget" data-sitekey="IHR_SITEKEY"></div>
<button type="submit">Gutschein einlösen</button>
</form>Beispiel für das Gutscheinformular. An der Kasse steht dasselbe Div, nur im unsichtbaren Modus.
- Formulare zählen
- Gutschein, Kontoanlage, Anmeldung, Bewertung, Kasse. Jedes Formular, das mit Ja oder Nein antwortet, gehört auf die Liste.
- Seiten trennen
- Je Formular eine eigene Seite im Dashboard. Nur so steht am Gutscheinfeld eine Aufgabe und an der Kasse keine.
- Token prüfen
- Vor dem Einlösen den Wert des Feldes byebot-token mit Ihrem API-Key bei /validate_token prüfen. Erst bei Antwort 200 rechnen Sie den Code an.
- Gleiche Antwort
- Antworten Sie bei einem ungültigen Code immer gleich, unabhängig vom Grund. Unterschiedliche Antworten sind selbst eine Auskunft über das Codeformat.
- Dokumentation
- Vollständige Anleitung
Zwei Grenzen sind wichtig genug, um sie auszuschreiben. Erstens ersetzt eine Formularprüfung keine Betrugsregeln im Zahlungsprozess. Zweitens hält sie Automatisierung nicht vollständig auf, sondern verteuert sie. Was Sie davon sehen, steht in Ihrer Auswertung als bestandene und abgewiesene Prüfungen je Tag, aufgeschlüsselt nach Land, Browserfamilie und Plattform. Zu den Statistiken und zur Bot-Erkennung.
Fragen zu Einbau, Abrechnung und Daten.
Kurze Antworten zu Bedrohungsnamen, Tokenprüfung, Abrechnung und Verarbeitungsort.
Wie nennt das OWASP Automated Threat Handbook diese Fälle?
Jeder Fall hat dort eine eigene Kennung. Diese Seite steht unter OAT-002 Token Cracking, dem Durchprobieren von Codes. Der automatisierte Aufkauf knapper Ware läuft unter OAT-005 Scalping, das Blockieren von Bestand unter OAT-021 Denial of Inventory und das Abgreifen von Preisen unter OAT-011 Scraping. Diese drei laufen nicht über ein Formular mit Absendeknopf, eine Formularprüfung sieht sie also nicht. Der bekannteste Fall, OAT-001 Carding, meint Versuche gegen eine Zahlungsautorisierung. Wir haben das Handbuch am 01.08.2026 im Original geprüft.
Wie prüfe ich das Token auf meinem Server?
Vor dem Einlösen prüfen Sie den Wert des Feldes byebot-token mit Ihrem API-Key bei /validate_token. Erst bei Antwort 200 rechnen Sie den Code an. Im Formular steht dafür ein Div mit Ihrem Sitekey, dazu ein Script-Tag; an der Kasse dasselbe Div im unsichtbaren Modus. Die vollständige Anleitung liegt in der Dokumentation.
Warum sollte die Antwort bei einem ungültigen Gutscheincode immer gleich lauten?
Weil unterschiedliche Antworten selbst eine Auskunft über das Codeformat sind. Antworten Sie bei einem ungültigen Code immer gleich, unabhängig vom Grund. Das Gutscheinfeld gibt bei jedem Versuch eine eindeutige Antwort und wird deshalb durchprobiert. Ein Code nach festem Muster ist kurz genug, um ihn zu erzeugen und der Reihe nach einzulösen.
Was steht in der Auswertung?
Bestandene und abgewiesene Prüfungen je Tag, aufgeschlüsselt nach Land, Browserfamilie und Plattform. Das ist der Teil, den eine Formularprüfung überhaupt sieht. Erkennungsereignisse werden 30 Tage aufbewahrt, die Statistik 365 Tage im Pro-Tarif und unbegrenzt im Enterprise-Tarif. Wie die einzelnen Prüfungen arbeiten, steht unter Bot-Erkennung.
Zählen abgewiesene Anfragen gegen mein Kontingent?
Nein. Berechnet wird eine Prüfung, die bis zur Verifikation kommt, ob sie besteht oder nicht. Vorab abgewiesene Anfragen zählen nicht gegen das Kontingent. Abweisungen durch Sperrliste, Länderfilter oder Ratenbegrenzung bleiben außen vor. Welche Regeln je Seite gelten, stellen Sie in der Zugriffskontrolle ein.
Wo verarbeitet ByeBot die Daten?
In Deutschland, in jedem Tarif und ohne Aufpreis. Die Auftragsverarbeitung läuft nach Art. 28 DSGVO, die eingesetzten Auftragsverarbeiter stehen unter byebot.de/datenschutz. Es gibt keine CAPTCHA-Cookies, kein seitenübergreifendes Tracking, kein Training von KI-Modellen an Besucherdaten und keine Weitergabe an Dritte. Auch keine Übermittlung in Drittländer.
Sieben Tage testen, dann entscheiden.
Ein Zahlungsmittel wird zu Beginn hinterlegt. In der Testphase liegt die Grenze bei 10.000 Prüfungen. Danach ab 19 € im Monat.