Salesforce et ServiceNow aspirés par un même attaquant
Depuis 2025, un même acteur aspire méthodiquement des portails SaaS d'entreprise, Salesforce et ServiceNow en tête. Pas avec une faille spectaculaire : en exploitant des accès mal cloisonnés et des données laissées trop ouvertes. C'est-à-dire les deux défauts les plus courants des applications récentes.
Ce qui s'est passé, en clair
Il n'y a pas eu d'effraction. L'attaquant a créé ou obtenu des comptes légitimes, puis il a simplement demandé plus que ce à quoi ces comptes avaient droit — et les applications ont répondu. Page après page, compte après compte, en automatique.
Le mécanisme est presque toujours le même : une adresse d'API renvoie une liste, et cette liste n'est pas filtrée sur qui la demande. Ou bien un identifiant de fiche se trouve dans l'adresse, et il suffit de changer le numéro pour tomber sur la fiche du voisin.
Pourquoi ça vous concerne
« On est trop petits pour intéresser quelqu'un » est la phrase qui coûte le plus cher. Ces attaques sont automatisées : personne ne vous a choisi, un programme balaie et s'arrête là où ça cède. Une application de dix clients se fait aspirer aussi vite qu'une de dix mille.
Et c'est précisément le point aveugle du code écrit avec l'IA. Elle produit sans faillir l'écran de connexion — ça, c'est visible, on le teste. Elle oublie beaucoup plus souvent de vérifier, à chaque requête, que ce compte-là a le droit de voir cette donnée-là. Et ça, ça ne se voit pas : l'application a l'air de parfaitement fonctionner.
Ce que vous pouvez vérifier vous-même
- Le test des deux comptes. Créez deux comptes clients. Connecté avec le premier, essayez d'atteindre une donnée du second en changeant l'identifiant dans l'adresse. Si ça s'affiche, vous avez votre réponse.
- Regardez ce que renvoient vraiment vos listes. Ouvrez les outils du navigateur, onglet Réseau : une liste qui renvoie des champs que l'écran n'affiche pas, c'est de la donnée qui sort quand même.
- Vérifiez côté serveur, pas côté écran. Cacher un bouton n'empêche personne d'appeler l'adresse qui se trouvait derrière.
- Testez un compte gratuit. C'est le point d'entrée préféré des attaquants : gratuit, immédiat, et souvent bien moins cloisonné qu'un compte payant.
Est-ce qu'un compte peut voir les données d'un autre, et est-ce que vos listes d'API renvoient plus que ce qu'elles devraient.