Le bombing SMS et OTP désigne des attaques dans lesquelles un bot déclenche de façon répétée un formulaire OTP ou d'inscription sur votre site web afin de générer des SMS en masse. Les motivations typiques sont le harcèlement de tiers ("SMS flood" sur un numéro cible), l'épuisement de votre crédit et surtout la fraude IRSF (International Revenue Share Fraud), où les attaquants envoient des SMS vers des numéros surtaxés internationaux coûteux sur lesquels ils touchent eux-mêmes une part.
Auf einen Blick
- Le déclencheur se trouve presque toujours dans le formulaire OTP : captcha, limite de débit et délai d'attente sont obligatoires.
- Chez seven, la restriction par pays est le principal moyen de limiter les dégâts.
- Imposer la signature HMAC des requêtes et une liste blanche d'IP rendent une clé API divulguée inutilisable.
- Un sous-compte ne sert de plafond que si la recharge automatique est désactivée.
- La 2FA, des clés API distinctes par service et une alerte de solde bas font partie de l'équipement de base.
Aucune fonctionnalité isolée ne protège contre cette classe d'attaques. Seule une protection échelonnée est efficace : d'abord dans votre application, puis dans votre compte seven.
Où se trouve la véritable faille
Dans la plupart des cas de bombing, le formulaire OTP n'est pas protégé : pas de captcha, pas de limite de débit, pas de délai d'attente. L'attaquant appelle le point d'envoi des centaines ou des milliers de fois par minute, et chaque appel génère un véritable SMS. seven peut limiter les dégâts, mais c'est à vous de fermer le déclencheur dans votre application.
Mesures de protection dans votre application
Ces points relèvent de votre frontend et de votre backend, pas de seven :
Captcha avant le bouton d'envoi. reCAPTCHA, hCaptcha, Cloudflare Turnstile ou une détection de bots comparable. C'est la mesure individuelle la plus efficace.
Limite de débit par IP, par session et par numéro de destinataire. Exemple : 3 OTP maximum par tranche de 10 minutes par numéro de mobile et 10 OTP maximum par heure par IP.
Délai d'attente entre les clics de renvoi. Premier renvoi après 60 secondes, puis backoff exponentiel (2, 4, 8 minutes).
Prévalidation des numéros. Vérifiez le format et l'opérateur via Lookup avant de déclencher le SMS. Vous filtrez ainsi les numéros invalides et les destinations surtaxées exotiques avant que des coûts ne soient générés.
Champs honeypot et analyse comportementale. Journalisez et bloquez les champs de formulaire cachés remplis, les envois anormalement rapides et les user agents atypiques.
Mesures de protection dans votre compte seven
Ces mesures plafonnent les dégâts si la couche applicative cède malgré tout.
Activer les restrictions par pays
De loin le levier le plus important contre l'IRSF. Si votre service OTP ne s'adresse qu'à des clients de quelques pays, bloquez tout le reste. Les attaques vers des numéros surtaxés tombent alors à l'eau, car seven ne distribue même pas le SMS.
Configuration sous Paramètres > Messages > Restrictions par pays. Pour plus de détails, voir Restrictions géographiques.
Tipp
Réglez "Reste" sur non autorisé et n'ajoutez comme autorisés que les pays de destination réellement nécessaires. Il s'agit d'une liste blanche qui bloque toutes les destinations surtaxées exotiques.
Activer et imposer la signature des requêtes
seven prend en charge la signature des requêtes HMAC-SHA256 pour l'API REST. Chaque requête API peut être signée avec une clé de signature distincte, attribuée indépendamment de la clé API. Une clé API volée est alors inutile à elle seule, à condition que vous activiez l'obligation de signature.
Fonctionnement :
Trois en-têtes accompagnent la requête :
X-Signature,X-Timestamp,X-Nonce.La signature HMAC-SHA256 porte sur une chaîne composée de l'horodatage, du nonce, de la méthode HTTP, de l'URL complète et du hash MD5 du corps (séparés par des sauts de ligne).
L'horodatage ne doit pas dater de plus de 30 secondes (protection contre le rejeu). Le nonce est unique par requête.
Configurez la clé de signature sous Developer > Settings. Dans la même section, vous activez l'obligation de signature afin que les requêtes non signées ou mal signées soient rejetées.
Documentation complète avec exemples Bash et PHP : docs.seven.io/en/rest-api/signing.
Wichtig
Conservez la clé de signature séparément de la clé API, idéalement dans un gestionnaire de secrets (p. ex. AWS Secrets Manager, HashiCorp Vault). Si les deux se trouvent côte à côte dans le même .env, l'effet protecteur disparaît.
Liste blanche d'IP serveur pour l'API
En complément de la signature des requêtes, limitez l'accès à l'API aux IP sources connues : seules les requêtes provenant des IP de vos serveurs applicatifs sont acceptées, toutes les autres sont rejetées avec l'erreur 903. Cela arrête aussi les attaques dans lesquelles la clé de signature et la clé API fuitent ensemble.
Configuration sous Developer > Settings > REST API. Pour plus de détails, voir Liste blanche pour l'accès à l'API.
Une clé API distincte par service
N'utilisez pas la même clé pour l'envoi marketing, les SMS transactionnels et les OTP. Une clé par service signifie qu'une seule clé divulguée peut être désactivée immédiatement sans interrompre les autres canaux d'envoi. Voir Où trouver ma clé API ? et Désactivation des clés API inutilisées.
Sous-compte uniquement comme plafond strict, pas avec la recharge automatique active
Un sous-compte dédié au service OTP sépare le crédit et le reporting. Il ne fonctionne toutefois comme plafond de dégâts que si la recharge automatique est désactivée et que vous l'alimentez manuellement. Sinon, un seuil bas entraîne simplement des recharges plus fréquentes, et le dommage total est identique, voire plus élevé.
Achtung
La recharge automatique sur un sous-compte OTP annule l'effet de plafond. Si vous voulez une limite stricte, désactivez la recharge automatique et rechargez manuellement.
Configuration recommandée :
un sous-compte dédié "OTP" avec sa propre clé API
recharge automatique désactivée
recharge manuelle avec un budget mensuel fixe (p. ex. 50 EUR)
dès que le sous-compte est vide, l'envoi s'arrête automatiquement
Détails sur la configuration : Sous-comptes.
Alerte de solde bas à plusieurs destinataires
Une vague d'envois inhabituelle entraîne inévitablement une baisse rapide du crédit. Définissez un seuil et au moins deux adresses de destinataires (technique et facturation) afin que l'alerte arrive aussi lorsqu'une personne est en congé. Voir Notification de solde bas.
Sécurité du compte
Imposez la 2FA à tous les membres du compte afin qu'un mot de passe volé ne suffise pas. Voir Authentification à deux facteurs (2FA) et Imposer l'authentification à deux facteurs (2FA).
Liste blanche d'IP pour la connexion en plus de la liste blanche de l'API, si vous travaillez depuis des IP de bureau fixes. Voir Liste blanche d'IP pour la connexion.
Désactivez les clés API inutilisées et passez-les régulièrement en revue.
Si une attaque est déjà en cours
Renouvelez ou désactivez immédiatement la clé API dans les paramètres développeur. Tout envoi supplémentaire s'arrête ainsi aussitôt.
Renforcez les restrictions par pays et bloquez tous les pays non ciblés.
Contactez le support à support@seven.io en indiquant votre ID de compte et la plage horaire. Nous vous aidons à analyser les schémas d'envoi et à endiguer l'attaque. Veuillez noter : les coûts des SMS déclenchés par une application non protégée du client ne sont en principe pas remboursés.
Sécurisez le côté applicatif avant de réactiver l'envoi. Intégrez un captcha, activez la limite de débit, analysez les journaux.
Notre support se tient à votre disposition pour tout incident concret.