C’est l’argument que tous les éditeurs SaaS adorent vous servir. Salesforce est ultra-sécurisée. Certifications ISO 27001, SOC 2, HDS, hébergement de classe mondiale, équipes sécurité internes au plus haut niveau du marché. Tout ça est vrai.
Et pourtant, en 2025, plusieurs centaines d’instances Salesforce ont été compromises selon les enquêtes publiées par la presse spécialisée — Google (TechCrunch), les marques du groupe LVMH (BleepingComputer), Adidas, Pandora, Allianz Life, Cisco. Des entreprises avec des moyens cybersécurité considérables.
Comment c’est possible ?
Réponse simple : aucune de ces attaques n’a exploité une faille de la plateforme Salesforce. Toutes ont exploité des erreurs de configuration côté client. Et c’est précisément le malentendu qui coûte le plus cher aux entreprises aujourd’hui. Salesforce est sécurisée. Votre instance, elle, ne l’est probablement pas.
Le mythe du CRM “100% sécurisé”
L’idée qu’un CRM SaaS soit “sécurisé par défaut” est une illusion confortable, mais dangereuse. Elle vient d’une confusion entre deux notions très différentes.
La première, c’est la sécurité de la plateforme elle-même. Le code de Salesforce, ses datacenters, ses certifications, ses processus internes de patching. Sur ce périmètre, Salesforce fait partie des éditeurs les plus avancés au monde. Vous n’avez aucune raison de vous inquiéter.
La seconde, c’est la sécurité de votre instance. Comment vos utilisateurs sont configurés. Qui a accès à quoi. Quelles applications tierces sont connectées via OAuth. Quels exports sont possibles. Quels comportements sont monitorés. Sur ce périmètre, Salesforce vous met à disposition des outils, mais ne fait absolument rien à votre place.
Et c’est là que le drame se joue. La plupart des dirigeants pensent acheter un produit qui s’occupe de tout. En réalité, ils achètent une plateforme qui leur transfère une part substantielle de la responsabilité sécurité, sans toujours bien le leur expliquer.
Cette confusion explique pourquoi la majorité des incidents Salesforce documentés en 2025 trouvent leur source dans une mauvaise configuration de l’instance, pas dans une faille de la plateforme.
Le modèle de responsabilité partagée expliqué simplement
Pour bien comprendre où s’arrête la responsabilité de Salesforce et où commence la vôtre, l’analogie la plus parlante est celle de l’immeuble sécurisé. Salesforce documente officiellement ce modèle sur son blog corporate.
Imaginez un immeuble haut de gamme. Le promoteur a construit des murs solides, installé un gardien 24/7 à l’entrée, posé des caméras dans les parties communes, doublé les portes principales d’un système d’accès par badge. C’est l’équivalent de ce que fait Salesforce : une infrastructure premium, robuste, monitorée, qui ferme la porte aux intrus.
Mais une fois dans votre appartement, c’est vous qui décidez. Qui a la clé. Combien d’invités peuvent entrer. Si vous laissez les fenêtres ouvertes en partant. Si vous installez un coffre-fort pour vos objets de valeur. Si vous activez une alarme intérieure. Le gardien à l’entrée ne sait pas, et ne saura jamais, ce qui se passe à l’intérieur de votre appartement.
C’est exactement ce qui se passe avec Salesforce. La plateforme se décompose en trois niveaux de responsabilité.
L’invisible : ce que gère Salesforce
L’infrastructure, la sécurité du code, les patches, la disponibilité, le chiffrement par défaut, la conformité aux certifications. Vous ne le voyez pas, vous n’avez pas à vous en occuper. Salesforce s’en charge. C’est l’équivalent du gardien et de la structure de l’immeuble.
Le configurable : ce que vous devez activer vous-même
Les droits utilisateurs, les profils, les permission sets, l’authentification multi-facteurs (MFA), les restrictions IP, le suivi des modifications (history tracking), le verrouillage de session, les politiques de mots de passe, la gestion des connected apps. Salesforce met tous ces leviers à disposition. C’est à vous de les activer correctement, et de les maintenir dans le temps.
Les solutions avancées : ce que vous pouvez ajouter
Event Monitoring pour la surveillance comportementale, Salesforce Shield pour le chiffrement renforcé et l’audit étendu (incluant Data Mask pour anonymiser les sandbox), Salesforce Backup & Recover pour la résilience. Ce sont des modules additionnels, payants, qui répondent à des enjeux spécifiques de conformité ou de sécurité avancée.
La règle est simple. Plus votre instance contient de données critiques, plus vous devez monter dans les niveaux 2 et 3. La majorité des entreprises s’arrêtent au niveau 1 par méconnaissance, et croient à tort qu’elles sont protégées.
Les erreurs de configuration les plus fréquentes
Ce qu’on observe sur le terrain, audit après audit, c’est toujours la même liste de défauts. Aucune n’est exotique. Toutes sont évitables.
Trop de droits administrateur
C’est le grand classique. Dans une instance qui a quelques années, on retrouve souvent une dizaine, parfois plusieurs dizaines de personnes avec les permissions “View All Data” ou “Modify All Data”. Anciens admins partis depuis longtemps, prestataires extérieurs dont la mission est terminée, équipes IT qui ont reçu un accès “le temps d’un projet” il y a trois ans.
Chaque compte avec ces droits est une porte ouverte sur l’intégralité de votre base. Si l’un de ces utilisateurs est compromis (phishing, vol de mot de passe, vishing), l’attaquant accède à tout.
MFA non activée ou contournable
Salesforce impose la MFA depuis 2022. Mais l’enforcement est imparfait. De nombreuses entreprises ont configuré la MFA sur leur SSO, sans bloquer la possibilité de connexion directe avec username + mot de passe en bypass de l’IdP. Résultat : la MFA est techniquement active, mais peut être contournée par un attaquant qui obtient des identifiants.
Autre piège classique : les comptes de service utilisés pour les intégrations API n’ont souvent pas de MFA. Et leurs mots de passe traînent dans des coffres mal protégés depuis des années.
Pas de restrictions IP
Salesforce permet de restreindre les connexions à des plages IP spécifiques (par exemple, le réseau de l’entreprise et un VPN). Très peu d’entreprises l’activent. Concrètement, cela signifie que n’importe qui, depuis n’importe où dans le monde, peut tenter de se connecter à votre instance avec un identifiant volé. Aucune barrière géographique.
Le piège du clonage de profil
L’erreur classique de l’admin pressé. Pour créer un nouveau profil utilisateur, il copie un profil existant. Sauf que le profil existant accumule depuis des années des permissions devenues caduques. Résultat documenté chez plusieurs clients : un nouveau commercial se retrouve avec l’API activée, l’export de masse autorisé, l’accès à des objets dont il n’a aucun usage métier.
C’est ce qu’on appelle le permission sprawl, ou la dérive des permissions. La rubrique Security de Salesforce Ben publie régulièrement des guides pratiques pour identifier et corriger ce phénomène. L’un des problèmes les plus difficiles à rattraper, car il faut auditer chaque profil et chaque permission set un par un.
Sharing model laxiste
Les Organization-Wide Defaults (OWD) sont parfois en “Public Read/Write” ou “Public Read Only” sur des objets sensibles, par confort de mise en place ou par méconnaissance. Conséquence : tous les utilisateurs voient toutes les données, même celles qui ne les concernent pas. Un commercial peut consulter les opportunités de l’autre BU, voir les comptes d’un concurrent géographique, accéder aux données financières de la maison mère.
Suivi d’historique non activé
Le Field History Tracking permet de tracer les modifications sur les champs critiques (montants d’opportunité, statut d’un compte, propriétaire d’un dossier). Sans ce suivi activé, en cas d’incident vous n’avez aucun moyen de savoir qui a modifié quoi, quand, depuis où. La forensic devient impossible.
Sites Experience Cloud mal configurés
Pour les entreprises qui exposent un portail client, le risque guest user est massif. Une mauvaise configuration des permissions invité peut exposer publiquement, sans authentification, des données qui devraient être privées. Salesforce a documenté plusieurs cas de fuites majeures liées à ce point précis.
Comment les attaques exploitent ces failles
Voici un scénario réaliste, construit à partir de cas observés en 2025, comme ceux documentés par Google Threat Intelligence sous le code UNC6040.
L’attaquant identifie sur LinkedIn un admin Salesforce dans votre entreprise. Il sait qu’il a un profil avec View All Data, parce que la fonction est mentionnée dans son profil professionnel.
Premier acte : il l’appelle, en se faisant passer pour le support IT interne. La voix est convaincante (potentiellement clonée par IA). Il prétexte un incident technique urgent, demande à l’admin de valider une connexion OAuth pour une application “interne”. L’admin valide. Pour rappel, CNN a documenté en février 2024 un cas où un employé du cabinet d’ingénierie Arup a transféré environ 25 millions de dollars après une visioconférence intégralement deepfakée. Le risque n’est plus théorique.
Deuxième acte : derrière cette validation OAuth, il s’agit en réalité d’une fausse application Data Loader configurée par l’attaquant. Le token OAuth émis donne un accès permanent à votre instance, qui ne nécessite plus de MFA pour fonctionner. Et comme vous n’avez pas activé Event Monitoring, vous ne voyez rien.
Troisième acte : depuis l’extérieur, l’attaquant utilise le token pour exfiltrer massivement vos données via API. Sans restriction IP en place, ces requêtes paraissent légitimes. Sans Transaction Security Policy plafonnant le volume API, rien ne s’interrompt. Plusieurs millions d’enregistrements quittent votre instance en quelques heures.
Quatrième acte : trois mois plus tard, vous recevez un email de demande de rançon. L’attaquant joint un échantillon de vos données pour prouver qu’il les détient.
Tous les maillons de cette chaîne d’attaque exploitent une mauvaise configuration. Pas une seule faille de Salesforce. Et chaque maillon aurait pu être brisé par une configuration correcte.
Pourquoi les entreprises sous-estiment ces risques
Trois raisons reviennent systématiquement.
La première, c’est l’illusion de sécurité. “On est sur Salesforce, c’est sécurisé.” Cette phrase, vous l’avez probablement déjà entendue dans une réunion. C’est la version SaaS de “on est dans le cloud, donc tout va bien”. Elle évacue d’un revers de main la responsabilité du client.
La deuxième, c’est le manque de formation. Salesforce est souvent géré par des équipes métier ou par des admins qui ont appris sur le tas. Les sujets sécurité, gouvernance des données, modèle de responsabilité partagée ne sont pas dans leur cœur de compétence. Et les RSSI, eux, considèrent souvent Salesforce comme “un outil métier” qui sort de leur périmètre.
La troisième, c’est la complexité perçue. Auditer une instance Salesforce, comprendre le permission sprawl, identifier les configurations à risque, ça demande une expertise spécifique. Beaucoup d’entreprises remettent à plus tard, jusqu’à l’incident.
Ce que font les entreprises matures
Les organisations qui ont compris l’enjeu ont structuré leur approche autour de quatre piliers.
Un audit régulier de la posture sécurité Salesforce. Au minimum une fois par an, idéalement après chaque release majeure de Salesforce ou changement organisationnel important. Cet audit balaie les profils, les permission sets, les connected apps, les OWD, les configurations de sécurité (MFA, IP, sessions), les sites Experience Cloud, les comptes de service. L’outil natif Health Check de Salesforce donne un premier score, mais ne suffit pas.
Une gouvernance formalisée des accès. Qui a le droit de demander quoi, qui valide, qui révoque, sous quels délais. Les nouveaux arrivants reçoivent un profil minimal et obtiennent des permissions additionnelles uniquement sur justification. Les départs déclenchent une désactivation immédiate. Les prestataires ont un accès limité dans le temps.
Le déploiement des outils avancés sur les instances critiques. Event Monitoring pour la visibilité, Shield pour le chiffrement renforcé et le Field Audit Trail, Data Mask pour les sandbox, Salesforce Backup & Recover pour la résilience. Ces investissements sont calibrés en fonction de la criticité des données.
Un monitoring continu plutôt que ponctuel. Les configurations dérivent dans le temps. Un profil peut être ouvert pour un projet et oublié. Une connected app peut être ajoutée sans validation. Un nouvel objet peut hériter d’un sharing public par défaut. Le monitoring continu (via les Transaction Security Policies temps réel, ou via des outils tiers spécialisés) permet de détecter ces dérives.
Conclusion : la sécurité est un processus, pas une option
Si vous retenez une seule chose de cet article, retenez celle-ci. La sécurité Salesforce ne s’achète pas avec votre licence. Elle se construit, se configure, s’audite, se maintient.
Le bon réflexe n’est pas de chercher la prochaine fonctionnalité miracle. C’est de poser un diagnostic objectif sur l’état actuel de votre instance et d’identifier les écarts avec les bonnes pratiques.
Chez Cloud Girafe, nous accompagnons les directions techniques et CRM dans l’audit complet de leur posture sécurité Salesforce. Nous balayons profils, permissions, configurations, connected apps, sharing model, et nous identifions les points de vulnérabilité concrets, priorisés par niveau de risque. À l’issue de l’audit, vous disposez d’un plan d’action clair pour remettre votre instance au niveau de protection que mérite votre activité.
Si en lisant cet article vous vous êtes dit “je ne suis pas sûr de l’état réel de notre configuration”, c’est probablement le signe qu’il faut en parler. Contactez-nous sur cloudgirafe.fr pour planifier un audit Salesforce.
