Missbrauch der OTP-Schnittstelle verhindern | OTP Deutsch

Wenn Skripte Ihren OTP-Versand wiederholt aufrufen, erhalten Nutzer Massen unerwünschter Codes, das Guthaben wird schnell verbraucht und der Ruf des Kanals kann sinken. EngageLab OTP kann Frequenz und Volumen auf der Sendeseite begrenzen, aber nicht einen nicht authentifizierten Endpunkt „Bestätigungscode abrufen“ in Ihrer Anwendung.

Dieser Artikel erklärt, wie Sie Plattformfunktionen mit anwendungsseitigem Schutz kombinieren, um API-Missbrauch zu reduzieren.

Korrekte Architektur

Die EngageLab OTP API darf nur von Ihrem Server aufgerufen werden. Rufen Sie sie nicht direkt aus Browser, App-Client oder Mini-Programm auf.

Nutzer → Ihr Frontend (Anmeldung / Registrierung / Passwort zurücksetzen) → Ihr Backend (Sitzungsprüfung, CAPTCHA, fachliche Ratenlimits) → EngageLab OTP API (mit API Key und end_user_ip)

              
              Nutzer → Ihr Frontend (Anmeldung / Registrierung / Passwort zurücksetzen)
     → Ihr Backend (Sitzungsprüfung, CAPTCHA, fachliche Ratenlimits)
     → EngageLab OTP API (mit API Key und end_user_ip)

Diesen Codeblock im schwebenden Fenster anzeigen

Speichern Sie dev_key und dev_secret nur auf dem Server. Legen Sie sie nicht in Frontend-Code, App-Pakete oder öffentliche Repositories.
Das Frontend soll nur Ihre eigene API „Bestätigungscode abrufen“ aufrufen. Verbinden Sie sich nicht direkt mit https://otp.api.engagelab.cc.
Konfigurieren Sie für Produktions-API-Keys eine IP-Whitelist der Aufrufer. Siehe API Key.

Die zwei IP-Typen nicht vermischen

Einstellung / Parameter	Einzutragen	Was es blockiert
IP-Whitelist des API Key	Die Ausgangs-IP Ihres Servers	Unbekannte IPs, die mit einem Key die OTP API direkt aufrufen
`end_user_ip` in der Sendeanfrage	Die IP des Endnutzers	Dieselbe Nutzer-IP, die in kurzer Zeit wiederholt Codes anfordert

Nachdem Sie in der Security-Center das Limit „nach IP-Adresse“ aktiviert haben, müssen Sie end_user_ip in der Anfrage OTP senden übergeben, damit das Limit greift. Übergeben Sie die öffentliche IP des Nutzergeräts, nicht die IP Ihres Servers.

Schutz auf der Plattformseite

Nehmen Sie in der OTP-Konsole folgende Einstellungen vor, um Schäden bei Missbrauch des Versands zu begrenzen:

Aufgabe	Wo	Zweck
IP-Whitelist und Gültigkeit für den API Key setzen und jederzeit deaktivierbar halten	API Key	Eingrenzen, wer die API aufrufen darf; bei Leak sofort deaktivieren
Frequenzlimits für dieselbe Nummer und dieselbe IP aktivieren	Security-Center	Wiederholte Sends an eine Nummer oder von einer IP blockieren
`end_user_ip` in der Sendeanfrage übergeben	OTP senden	IP-basiertes Ratenlimit wirksam machen
Tägliche / monatliche Warn- und Kontingentwerte setzen	Security-Center	Bei ungewöhnlichem Volumen alarmieren oder automatisch pausieren
Whitelist oder Blacklist nach Land / Region setzen	Security-Center	Versand in geschäftsfremde Regionen vermeiden
Den SMS-Kanal im Notfall mit einem Klick pausieren	Security-Center	Während eines Angriffs schnell Verluste stoppen

Damit Sie bei Warn- oder Kontingentüberschreitung benachrichtigt werden, konfigurieren Sie zuerst das Callback-Ereignis in Webhook.

Schutz auf der Anwendungsseite

Plattformlimits ersetzen nicht den Schutz Ihrer eigenen API „Bestätigungscode abrufen“. Führen Sie diese Prüfungen aus, bevor Sie EngageLab aufrufen:

Führen Sie vor dem Versand ein CAPTCHA aus (z. B. Bild-CAPTCHA, Turnstile oder reCAPTCHA) und prüfen Sie das Ergebnis serverseitig.
Legen Sie für dieselbe Rufnummer ein erneutes Sendeintervall fest (z. B. 60 Sekunden) und zeigen Sie im Frontend einen Countdown.
Begrenzen Sie Anfragen pro Konto, Gerät und IP nach Minute, Stunde und Kalendertag. Zählen Sie auch fehlgeschlagene Anfragen.
„Bestätigungscode abrufen“ muss eine angemeldete Sitzung oder in nicht angemeldeten Flows eine gültige Session haben. Stellen Sie keinen öffentlichen Sendeendpunkt ohne Kontext bereit.
Begrenzen Sie Versuche für denselben Code und ungültig machen Sie ihn nach erfolgreicher Prüfung sofort. EngageLab OTP unterstützt keine erneute Prüfung eines bereits verifizierten Codes.

Fehlercodes als Missbrauchssignal nutzen

OTP senden kann in der Prüfung vor dem Versand folgende Fehler zurückgeben. Verlangsamen Sie dann Wiederholungen und prüfen Sie auf konzentrierten Traffic:

Fehlercode	HTTP-Status	Bedeutung
`3004`	400	Frequenzlimit für dieselbe Vorlage und denselben Empfänger überschritten; das Fenster richtet sich nach der Vorlagenkonfiguration
`6001`	429	Sendefrequenz für dieselbe Rufnummer überschritten; das Fenster kann Minute, Stunde oder Kalendertag sein
`6002`	429	Sendefrequenz für dieselbe Endnutzer-IP überschritten; wird nur geprüft, wenn `end_user_ip` übergeben wird
`6003`	429	Das globale Tages- oder Monatsvolumen der Anwendung hat das Limit erreicht
`6007`	403	Der SMS-OTP-Versand ist pausiert, für alle oder das aktuelle Land / die aktuelle Region

Wiederholen Sie bei HTTP 429 nicht sofort in dichter Folge. Prüfen Sie bei anhaltenden Fehlern zuerst im Security-Center, ob ein Volumenlimit oder ein Notfallstopp aktiv ist, und kontaktieren Sie dann den Support.

Vorgehen bei geleaktem Secret

In der OTP-Konsole den API Key deaktivieren oder rotieren.
Im Security-Center den Notfallstopp nutzen und den SMS-Versand pausieren.
Ungewöhnliche Sends in Verlauf und Callbacks prüfen.
Die IP-Whitelist des API Key enger fassen und prüfen, ob Tages- / Monatslimits angemessen sind.
Den Versand erst fortsetzen, wenn das Risiko beseitigt ist.

Checkliste vor dem Go-live

Die API wird nur vom Server aufgerufen. dev_secret liegt nicht im Frontend, in der App oder in einem öffentlichen Repository.
Der Produktions-API-Key hat eine Whitelist der Server-Ausgangs-IP.
Frequenzlimits pro Nummer sind im Security-Center aktiv; bei IP-Limits enthalten Sendeanfragen end_user_ip.
Tages- / Monatslimits sind gesetzt und volumenbezogene Callbacks konfiguriert.
Die API „Bestätigungscode abrufen“ führt CAPTCHA und fachliche Limits aus, bevor EngageLab aufgerufen wird.
Die Reihenfolge bei Missbrauch ist klar: Key deaktivieren → Notfallstopp → Sendedatensätze prüfen.