Unbefugte Nutzung der SMS-API verhindern

Wenn die SMS-Sende-API ohne Autorisierung aufgerufen wird oder ein API Key nach einem Leak missbraucht wird, können Nachrichten in großer Menge ausgehen, das Guthaben schnell verbraucht werden und der Ruf des Kanals sinken. EngageLab SMS kann Frequenz, Volumen und Länder- / Regionsumfang auf der Sendeseite begrenzen, ersetzt aber nicht den Schutz Ihrer Secrets und Ihrer eigenen Sendeeingänge.

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

Korrekte Architektur

Die EngageLab SMS API darf nur vom Server Ihres Geschäftssystems aufgerufen werden. Rufen Sie sie nicht direkt aus Browser, App-Client oder Mini-Programm auf.

              
              Geschäftssystem-Server → EngageLab SMS API (mit API Key; bei seitenausgelöstem Versand zusätzlich end_user_ip)

            

• Speichern Sie dev_key und dev_secret nur auf dem Server. Legen Sie sie nicht in Frontend-Code, App-Pakete, öffentliche Repositories oder Klartext-CI-Variablen.
• Stellen Sie die SMS-API-URL und Secrets nicht über einen Endpunkt bereit, den Endnutzer direkt aufrufen können.
• Konfigurieren Sie für Produktions-API-Keys eine IP-Whitelist der Aufrufer. Siehe API Key.

Die zwei IP-Typen nicht vermischen

Nachdem Sie in der Security-Center das Limit „nach IP-Adresse“ aktiviert haben, müssen Sie end_user_ip in der Anfrage SMS senden übergeben, damit das Limit greift. Übergeben Sie die öffentliche IP des Nutzergeräts, nicht die IP Ihres Servers. Beim serverseitigen Massenversand von Marketing- oder Benachrichtigungs-SMS ohne Endnutzer-IP greift das IP-Limit für diese Anfrage nicht. Verlassen Sie sich stärker auf die API-Key-Whitelist und Sendevolumenkontingente.

Schutz auf der Plattformseite

Nehmen Sie in der SMS-Konsole folgende Einstellungen vor, um Schäden bei Missbrauch der API zu begrenzen:

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

Schutz nach Vorlagentyp verstärken

Unterschiedliche Vorlagentypen werden unterschiedlich missbraucht, daher liegt der Schutzschwerpunkt woanders.

Benachrichtigungs- / Marketingvorlagen

Diese SMS werden in der Regel serverseitig anhand von Geschäftsereignissen oder Kampagnen stapelweise gesendet. Das Hauptrisiko ist ein geleakter Key, der für Massenversand genutzt wird.

• Produktionsumgebungen müssen eine API-Key-IP-Whitelist verwenden.
• Legen Sie angemessene Tages- / Monatslimits für die App fest, damit das Guthaben nicht in einem Schub aufgebraucht wird.
• Starten Sie geplante oder Stapeljobs nur in einer kontrollierten Serverumgebung. Stellen Sie den Versand nicht als unauthentifizierten HTTP-Endpunkt bereit.

Bestätigungscode-Vorlagen

Wenn Sie eine Bestätigungscode-Vorlage nutzen und der Versand über die Schaltfläche „SMS abrufen“ auf Website oder App ausgelöst wird, schützen Sie zusätzlich Ihre eigene Geschäfts-API:

• 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.
• „SMS abrufen“ muss eine angemeldete Sitzung oder in nicht angemeldeten Flows eine gültige Session haben. Stellen Sie keinen öffentlichen Sendeendpunkt ohne Kontext bereit.

Fehlercodes als Anomaliesignal nutzen

SMS senden kann bei der Prüfung oder beim Versand folgende frequenzbezogene Fehler zurückgeben. Verlangsamen Sie dann Wiederholungen und prüfen Sie auf unbefugte Aufrufe oder konzentrierten Traffic:

Wenn das Sendevolumen das Security-Center-Kontingent bereits erreicht hat oder Sie den Notfallstopp ausgeführt haben, werden Folgeanfragen abgelehnt. Prüfen Sie zuerst den Status im Security-Center. Wiederholen Sie nicht sofort in dichter Folge.

Vorgehen bei geleaktem Secret

1. In der SMS-Konsole den API Key deaktivieren oder rotieren.
2. Im Security-Center den Notfallstopp nutzen und den SMS-Versand pausieren.
3. Ungewöhnliche Sends in Nachrichtendetails und Callbacks prüfen.
4. In Benachrichtigungseinstellungen prüfen, ob eine Guthabenwarnung ausgelöst wurde, und den jüngsten Verbrauch abgleichen.
5. Die IP-Whitelist des API Key enger fassen und prüfen, ob Tages- / Monatslimits angemessen sind.
6. 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, in einem öffentlichen Repository oder in Klartext-CI-Variablen.
• Der Produktions-API-Key hat eine Whitelist der Server-Ausgangs-IP.
• Frequenzlimits pro Nummer sind im Security-Center aktiv; seitenausgelöste Sends enthalten end_user_ip.
• Tages- / Monatslimits sind gesetzt, volumenbezogene Callbacks und Guthabenwarnungen sind konfiguriert.
• Bestätigungscode-Sends führen CAPTCHA und fachliche Limits aus, bevor EngageLab aufgerufen wird.
• Die Reihenfolge bei Missbrauch ist klar: Key deaktivieren → Notfallstopp → Sendedatensätze prüfen.