So verhindern Sie Bot-Registrierungen auf Ihrer Website

Kontrollen auf dem Server durchsetzen

Prüfen Sie das Format im Formular, damit Menschen Eingabefehler sofort korrigieren können. Validieren Sie die Eingaben anschließend erneut auf dem Server. Ein E-Mail-Feld im Browser prüft die Form einer Adresse. Es kann weder die Existenz eines Postfachs feststellen noch direkte HTTP-Anfragen verhindern. MDN erklärt, warum beide Validierungsschritte nötig sind.

Begrenzen Sie die Anfragerate am Registrierungsendpunkt und beim Versand von Bestätigungs-E-Mails. Wählen Sie die Grenzen anhand Ihres Datenverkehrs und der Kosten einer Kontoerstellung. Viele berechtigte Besuche können dieselbe IP-Adresse nutzen. Ein Honeypot ist ein zusätzliches Formularfeld, das Menschen nicht ausfüllen sollen. Es kann einfache automatisierte Einsendungen kennzeichnen. Prüfen Sie es auf dem Server und testen Sie, ob automatische Eingabehilfen oder assistive Werkzeuge zu falschen Ablehnungen führen. Aufwendigere Skripte können das Feld leer lassen.

Geben Sie teure Testfunktionen oder andere Vorteile erst frei, wenn Ihre Voraussetzungen erfüllt sind. Betrachten Sie Häufungen neuer Konten zusammen mit deren anschließender Nutzung. Diese Anwendungskontrollen entsprechen dem mehrstufigen Ansatz in den OWASP-Empfehlungen gegen Automatisierung. Anfragelimits, Honeypots und Beschränkungen für Testzugänge setzen Sie selbst um. Signup Protection liefert oder konfiguriert sie nicht.

Token beim Anzeigen des Formulars abrufen

Emvero Signup Protection vergleicht die Verbindung, die einen Seitentoken abgerufen hat, mit der Anfrage, die Ihr Formular absendet. Die E-Mail-Entscheidung erhält dadurch zusätzliche Belege zum Besuch. Das Ergebnis ist weder ein Wahrheitswert für Mensch oder Bot noch eine dauerhafte Besucher-ID. Wiederholte Kontoerstellungen über mehrere Besuche werden nicht gezählt.

Öffnen Sie Signup Protection in Ihrem Konto, aktivieren Sie die Verbindung und warten Sie, bis sie bereit ist. Erstellen Sie einen Seitenschlüssel für die HTTPS-Origins Ihres Formulars. Der Seitenschlüssel fp_key_… ist öffentlich und gehört in den Browser. Der geheime API-Schlüssel emv_… bleibt auf Ihrem Server.

Laden Sie fp-token.js und die separat bereitgestellte Datei fp-probe.js mit dem Kundencode Ihres Kontos. Legen Sie im Formular ein verstecktes Feld an, beispielsweise fp_token. Erstellen Sie FpToken mit Endpunkt, Seitenschlüssel und Optionen, sobald das Formular sichtbar wird. Rufen Sie dann visitToken.fetch(vid) auf. Bei einem von Anfang an sichtbaren Formular starten Sie nach dem Laden der Seite. Bei einem Dialog warten Sie, bis er geöffnet wird. Beachten Sie erforderliche Einwilligungen. Die Option { quic: true } aktiviert eine optionale WebTransport-Sitzung.

vid ist eine undurchsichtige Kennung für den Besuch, übergeben als Zeichenfolge oder Promise. Verwenden Sie keine Konto-ID, E-Mail-Adresse oder Telefonnummer. fetch(vid) liefert ein Promise, das zum Token oder zu einer leeren Zeichenfolge aufgelöst wird. Ihr Code schreibt dieses Ergebnis in das versteckte Feld; die Bibliothek aktualisiert das Feld nicht. Fehlt die Datei für die Browserprüfung oder ist sie inkompatibel, erhalten Sie keinen Token. Bei einem nutzbaren Token kann eine einzelne Browserprüfung trotzdem nicht ausgewertet sein.

Beginnen Sie die Erfassung, während die Person das Formular sieht und ausfüllen kann. Ein Abruf erst beim Absenden kann den Befund für ungewöhnlich schnelles Absenden auslösen. Rufen Sie bei langen Formularen vor Ablauf des Tokens erneut visitToken.fetch() auf und aktualisieren Sie das Feld. Die Browserprüfung hält einen nutzbaren vorherigen Token im Seitenspeicher. Bei einem nutzbaren vorherigen Token bleibt der erste Ausstellungszeitpunkt nur erhalten, wenn die IPv4-Adresse beziehungsweise das IPv6-/64-Präfix sowie Browserfamilie, Hauptversion und Plattform gleich bleiben und der Besuch höchstens 24 Stunden alt ist. Andernfalls beginnt die Zeitmessung neu. Wird das Formular kurz danach abgesendet, kann der Befund für ungewöhnlich schnelles Absenden entstehen. Das aktuelle Profil verwendet eine Gültigkeitsdauer von 15 Minuten. Senden Sie den jeweils aktuellen Feldwert unverändert mit dem Formular.

Scheitert das Skript oder die Tokenanfrage, kann das Feld leer bleiben und das Formular trotzdem abgesendet werden. Behandeln Sie dieses Ergebnis auf Ihrem Server. Die Einbettungsanleitung beschreibt Skript, erlaubte Origins, Erneuerung und Content Security Policy. Die Datei für die Browserprüfung wird getrennt vom Tokenskript aktualisiert. Ist sie blockiert oder nicht verfügbar, erhalten Sie keinen Token. Auch mit einem nutzbaren Token kann eine einzelne Browserprüfung als nicht ausgewertet gemeldet werden.

Serverprüfung auswählen

Mit POST /v1/signup-checks prüfen Sie E-Mail und Besuch gemeinsam. Senden Sie email, den Wert des versteckten Felds als token sowie die von Ihrem Server erfassten Werte ip, user_agent und verfügbare client_hints. Leiten Sie hinter einem Proxy die Client-IP aus Ihrer vertrauenswürdigen Proxy-Konfiguration ab. Vertrauen Sie keinem Formularfeld, das angeblich diese IP enthält.

Wenn Sie die E-Mail bereits an anderer Stelle oder erst später prüfen, verwenden Sie POST /v1/signup-signals ohne email und variant. Dessen Aktion beruht allein auf Signalen und ersetzt Ihre E-Mail-Regeln nicht. Fehlende Anfragedaten begrenzen die möglichen Vergleiche. Sie belegen nicht, dass ein Vergleich bestanden wurde.

Ausgewertete Signale kosten fünf Credits. Für die Signalergebnisse token_unusable und unavailable fallen keine Signal-Credits an. Bei einer kombinierten Prüfung wird die E-Mail getrennt berechnet. Vor dem Start muss das Guthaben die angeforderten Reservierungen abdecken. Weitere Informationen finden Sie unter Preise und Credit-Rechner und im Anfrage- und Antwortvertrag.

Aktion mit dem Kontozugang verbinden

Setzen Sie die äußere action der kombinierten Antwort anhand der obigen Tabelle um. Halten Sie email.status, signals.status und action im Code getrennt. Signale können eine E-Mail-Bestätigung verlangen, aber kein reject auslösen. Sie schwächen die E-Mail-Entscheidung niemals ab.

Bei allow_with_email_confirmation sendet Ihre Anwendung eine Bestätigungsnachricht. Sie prüft deren Link oder Code, bevor sie den betreffenden Zugang freigibt. Die E-Mail-Prüfung von Emvero sendet keine Nachricht an die geprüfte Adresse. Eine Bestätigung belegt die Kontrolle über ein Postfach, nicht die Eindeutigkeit einer Person. Der Leitfaden zur Formularvalidierung erklärt E-Mail-Ergebnisse. Der Beitrag über Verifizierung und Bestätigung erläutert die beiden Vorgänge.

Die Browserbefunde fp_probe_forged und fp_probe_automation verlangen eine Bestätigung, wenn die E-Mail sonst eine Registrierung erlauben würde. fp_probe_tampering ist informativ. Das separate Array signals.notes enthält neben Beobachtungen zu Verbindung und Browser auch bot_claim und bot_operator. Diese Hinweise unterscheiden angegebene Crawler und Werkzeuge, ohne die Standardaktion zu ändern. Auch eine Crawlerangabe außerhalb des Betreibernetzes ist informativ. Eine fehlende Angabe belegt keinen menschlichen Besuch.

signal_codes zeigt, welche Befunde die Aktion verschärft haben. signals.findings enthält die ausführlicheren Belege. E-Mail-reason_codes bleiben innerhalb von email. VPN-, Tor-, Proxy- und Hosting-Befunde sind standardmäßig informativ und verschärfen die Aktion allein nicht.

Unvollständige Prüfungen und Fehler getrennt behandeln

Ein leerer Token erzeugt signals.status: token_unusable mit fp_token_absent. Wenn die E-Mail die Registrierung sonst erlauben würde, ist eine Bestätigung erforderlich. Bei einem Ausfall des Signaldiensts lautet der Status signals.status: unavailable. Die kombinierte Aktion folgt dann allein der E-Mail. Legen Sie fest, welchen Zugang Ihre Anwendung während eines solchen Ausfalls erlaubt. Nicht verfügbare Signale belegen keinen sicheren Besuch.

Solange email.status den Wert pending hat, bleibt die Bestätigung erforderlich. Rufen Sie nach email.retry_after_ms den Endpunkt GET /v1/signup-checks/{id} auf. Er liefert gespeicherte Signale mit dem aktuellen E-Mail-Ergebnis und berechnet die Aktion neu. Der Besuch wird dabei nicht erneut ausgewertet. Ein E-Mail-Ergebnis unknown bezeichnet Unsicherheit, keine festgestellte Ungültigkeit der Adresse.

Ein HTTP-Fehler ist ein eigenes Integrationsergebnis. Korrigieren Sie nach 400 fehlerhafte Felder, prüfen Sie nach 402 das Guthaben und behandeln Sie nach 409 signup_protection_disabled eine deaktivierte Verbindung. Beachten Sie Retry-After bei wiederholbaren Begrenzungen oder einer noch laufenden Anfrage. Ein Abrechnungsfehler ist keine Registrierungsentscheidung. Bewahren Sie den Versuch auf und folgen Sie den API-Anweisungen zu Fehlern und Wiederholungen. Eine kombinierte Anfrage kann die Signalauswertung starten, bevor die E-Mail-Reservierung scheitert. 402 garantiert deshalb nicht, dass keine Signalanfrage ausgeführt wurde.

Mit demselben Vorgangsschlüssel sicher wiederholen

Erstellen Sie einen Idempotency-Key pro logischem Registrierungsversuch. Bewahren Sie Schlüssel und Anfrageinhalt für eine Wiederholung nach einem Übertragungsfehler auf. Innerhalb des 30-minütigen Wiederholungsfensters liefern derselbe Schlüssel und Inhalt die gespeicherte Prüfung ohne zweite Belastung. Ein geänderter Inhalt mit diesem Schlüssel führt zu 409 idempotency_conflict. Solange die erste Anfrage läuft, fordert 409 request_in_progress zum Warten auf.

Denselben Token in einem neuen Vorgang zu senden ist etwas anderes, als den ursprünglichen Vorgang zu wiederholen. Wird der Token innerhalb seines Wiederverwendungsfensters für dasselbe Konto erneut vorgelegt, kann fp_token_reused hinzukommen und eine Bestätigung verlangen. Erzeugen Sie keinen neuen Schlüssel, nur weil die erste Antwort verloren ging. Für einen neuen Versuch verwenden Sie einen neuen Formulartoken. Der Idempotenzvertrag beschreibt die Wiederholungsgrenze.

Seite und Server gemeinsam testen

Eine bereite Verbindung, ein erstellter Seitenschlüssel und ein kopierter Beispielcode sind Einrichtungsschritte. Bestätigen Sie die Installation mit einer ausgewerteten Prüfung von Ihrem eigenen Formular und Server. Die folgenden Fälle sind Tests, keine Messungen realer Besuche:

• Füllen Sie ein gewöhnliches Formular nach Beginn der Erfassung aus. Prüfen Sie, ob Ihr Server Token und erfasste Anfragedaten erhält und die äußere Aktion umsetzt. Auch ein unauffälliger Besuch liefert nicht garantiert allow.
• Senden Sie das Formular ohne Token. Prüfen Sie, ob Ihre Anwendung token_unusable erhält und die erforderliche Postfachbestätigung anbietet.
• Simulieren Sie in Ihrer Testumgebung unavailable für Signale und pending für die E-Mail. Prüfen Sie die Ausfallregel und das wiederholte Abfragen gespeicherter Prüfungen getrennt.
• Wiederholen Sie dieselbe Anfrage mit ihrem gespeicherten Schlüssel. Testen Sie anschließend einen neuen Vorgang mit demselben Token. Prüfen Sie den Unterschied zwischen einer Wiederholung und fp_token_reused.
• Testen Sie eine abgelehnte E-Mail-Adresse und einen informativen Netzwerkbefund. Die E-Mail-Ablehnung muss bestehen bleiben. Eine Netzwerkkennzeichnung allein darf nicht zu einer Ablehnung durch Emvero werden.

Beobachten Sie Entscheidungen, unvollständige Prüfungen, abgeschlossene Bestätigungen und den Zugriff auf Testvorteile. Halten Sie Tokens und geheime Schlüssel aus Protokollen heraus. Passen Sie die Grenzen Ihrer Anwendung anhand beobachteten Missbrauchs und fehlgeschlagener berechtigter Registrierungen an. Emvero bietet weder einen Editor für eigene Registrierungsregeln noch einen fertigen CMS-Connector.