Empêcher l'utilisation non autorisée de l'API SMS

Si l'API d'envoi SMS est appelée sans autorisation, ou si une API Key fuitée est réutilisée, des messages peuvent partir en grande quantité, le solde est consommé rapidement et la réputation du canal peut baisser. EngageLab SMS peut limiter la fréquence, le volume et la portée pays / région côté envoi, mais ne remplace pas la protection de vos secrets et de vos propres points d'entrée d'envoi.

Cet article explique comment combiner les capacités de la plateforme et les protections métier pour réduire l'utilisation non autorisée de l'API.

Architecture correcte

L'API EngageLab SMS ne doit être appelée que depuis le serveur de votre système métier. Ne l'appelez pas directement depuis un navigateur, une application cliente ou un mini-programme.

              
              Serveur du système métier → API EngageLab SMS (avec API Key ; ajouter end_user_ip pour un envoi déclenché par une page)

            

• Conservez dev_key et dev_secret uniquement côté serveur. Ne les placez pas dans le code frontend, les paquets d'application, un dépôt public ou des variables CI en clair.
• N'exposez pas l'URL de l'API SMS ni les secrets sur un point de terminaison que les utilisateurs finaux peuvent appeler directement.
• Pour les API Key de production, configurez une liste blanche d'IP appelantes. Voir API Key.

Ne pas mélanger les deux types d'IP

Après avoir activé la limite « par adresse IP » dans le Centre de sécurité, vous devez transmettre end_user_ip dans la requête Envoyer un SMS pour que la limite s'applique. Transmettez l'IP publique de l'appareil utilisateur, pas celle de votre serveur. Pour un envoi marketing ou de notification en masse côté serveur sans IP d'utilisateur final, la limitation par IP ne s'applique pas à cette requête. Appuyez-vous davantage sur la liste blanche de l'API Key et les quotas de volume.

Protections côté plateforme

Effectuez la configuration suivante dans la console SMS pour limiter les pertes en cas d'utilisation abusive de l'API :

Pour recevoir une notification lorsqu'une alerte ou un quota est atteint, configurez d'abord l'événement de callback dans Webhook.

Renforcer la protection selon le type de modèle

Les types de modèles ne sont pas abusés de la même façon ; le focus de protection change.

Modèles de notification / marketing

Ces SMS sont généralement envoyés en masse depuis le serveur selon des événements métier ou des campagnes. Le risque principal est une clé fuitée utilisée pour un envoi de masse.

• Les environnements de production doivent configurer une liste blanche IP d'API Key.
• Définissez des quotas d'envoi journaliers / mensuels raisonnables pour l'application, afin que le solde ne soit pas vidé d'un coup.
• Déclenchez les tâches planifiées ou en masse uniquement dans un environnement serveur contrôlé. N'ouvrez pas l'envoi via un point HTTP non authentifié.

Modèles de code de vérification

Si vous utilisez un modèle de type code de vérification et que l'envoi est déclenché par le bouton « Obtenir le SMS » sur un site ou une application, protégez aussi votre propre API métier :

• Effectuez une vérification humaine (CAPTCHA image, Turnstile ou reCAPTCHA) avant l'envoi, et validez le résultat côté serveur.
• Définissez un intervalle de renvoi pour le même numéro (par exemple 60 secondes) et affichez un compte à rebours sur le frontend.
• Limitez les requêtes par compte, appareil et IP à la minute, à l'heure et au jour calendaire. Comptez aussi les requêtes en échec.
• « Obtenir le SMS » doit inclure une session connectée, ou une session valide hors connexion. N'exposez pas un point d'envoi public sans contexte.

Traiter les codes d'erreur comme des signaux d'anomalie

Envoyer un SMS peut renvoyer les erreurs de fréquence suivantes lors de la validation ou de l'envoi. Ralentissez alors les nouvelles tentatives et vérifiez s'il y a des appels non autorisés ou un trafic concentré :

Si le volume d'envoi a déjà atteint le quota du Centre de sécurité, ou si vous avez exécuté l'arrêt d'urgence, les requêtes suivantes sont rejetées. Confirmez d'abord l'état dans le Centre de sécurité. Ne relancez pas immédiatement en boucle.

Que faire en cas de fuite de secret

1. Dans la console SMS, désactivez ou faites tourner l'API Key.
2. Dans le Centre de sécurité, utilisez l'arrêt d'urgence pour suspendre l'envoi SMS.
3. Vérifiez les envois anormaux dans Détails des messages et les callbacks.
4. Vérifiez dans Paramètres d'alerte si une alerte de solde a été déclenchée et rapprochez la consommation récente.
5. Resserrer la liste blanche IP de l'API Key et vérifier si les quotas journaliers / mensuels sont raisonnables.
6. Reprenez l'envoi uniquement une fois le risque écarté.

Liste de contrôle avant mise en production

• L'API n'est appelée que depuis le serveur. dev_secret n'est pas dans le frontend, l'application, un dépôt public ou des variables CI en clair.
• L'API Key de production a une liste blanche d'IP de sortie du serveur.
• Les limites de fréquence par numéro sont activées dans le Centre de sécurité ; les envois déclenchés par une page incluent end_user_ip.
• Les quotas journaliers / mensuels sont définis, et les callbacks liés au volume ainsi que les alertes de solde sont configurés.
• Les envois de type code de vérification exécutent CAPTCHA et limites métier avant d'appeler EngageLab.
• L'ordre de réaction en cas d'abus est clair : désactiver la Key → arrêt d'urgence → examiner les enregistrements d'envoi.