Top 10 des vulnérabilités les plus fréquentes détectées sur la surface d'attaque externe des entreprises

En cybersécurité, l'imaginaire collectif évoque souvent des attaques sophistiquées, des groupes cybercriminels organisés ou des failles inédites découvertes par des chercheurs. Pourtant, la réalité du terrain est souvent plus prosaïque.

C'est un constat que nous faisons quotidiennement chez Board of Cyber. Parmi les organisations évaluées en continu par notre solution de notation cyber Security Rating, les mêmes vulnérabilités reviennent fréquemment d'une entreprise à l'autre, quelle que soit leur taille ou leur secteur d'activité. Des faiblesses rarement spectaculaires, mais très répandues.

Ce constat n'a rien d'anecdotique. Selon le Data Breach Investigations Report 2026 de Verizon, l'exploitation de vulnérabilités est devenue le premier vecteur d'accès initial lors des compromissions, devant le vol d'identifiants. Les attaquants n'ont pas toujours besoin d'innover : des erreurs de configuration, des mécanismes de sécurité absents ou des technologies qui ne sont plus maintenues à jour leur offrent régulièrement un point d'entrée.

Cet article présente les 10 vulnérabilités les plus fréquemment observées par Security Rating sur la surface d'attaque externe des organisations, ainsi que les mesures concrètes à mettre en œuvre pour les corriger. Ces mêmes faiblesses peuvent également concerner les fournisseurs de l'entreprise et s'inscrire dans une démarche de gestion des risques tiers (TPRM), à l'heure où les attaques via la supply chain se multiplient et peuvent avoir des conséquences considérables.

Les 10 vulnérabilités abordées dans cet article :

1. Ports d'administration exposés sur internet - SSH, RDP, VNC
2. Bases de données accessibles publiquement
3. Services internes accessibles publiquement - LDAP, SNMP, API Docker
4. Logiciels obsolètes et CVE non corrigées
5. Protocoles SSL/TLS obsolètes
6. Suites de chiffrement faibles
7. Certificats TLS invalides, expirés ou auto-signés
8. Headers de sécurité HTTP manquants ou mal configurés
9. SPF, DKIM et DMARC absents ou mal configurés
10. DNSSEC non déployé et Wildcard DNS

1. Ports d'administration exposés sur internet - SSH, RDP, VNC

Des protocoles tels que SSH, RDP, VNC ou Telnet permettent d'administrer à distance des serveurs et des équipements. Lorsqu'ils sont accessibles directement depuis internet, ils le deviennent également pour des attaquants potentiels.

Même en l'absence de vulnérabilité logicielle connue, cette exposition élargit inutilement la surface d'attaque : tentatives de force brute, réutilisation d'identifiants compromis ou exploitation ultérieure d'une faille affectant ces services. Le risque ne provient donc pas uniquement des vulnérabilités logicielles, mais aussi de l'exposition elle-même.

Le DBIR 2026 de Verizon rappelle que l'utilisation d'identifiants volés ou compromis demeure l'un des leviers d'intrusion les plus exploités. En cumulant les différentes étapes de la chaîne d'attaque, cette technique intervient dans 39 % des compromissions. Un service d'administration exposé sans restriction d'accès devient donc une cible de choix.

Comment corriger :

• Recenser les interfaces et services d'administration accessibles depuis internet.
• Identifier ceux qui doivent rester accessibles à distance pour des besoins opérationnels.
• Supprimer l'exposition publique des services qui ne le nécessitent pas.
• Mettre en place un VPN, un bastion d'administration ou des listes d'adresses IP autorisées pour les accès indispensables.
• Activer une authentification multifacteur et appliquer des politiques de mots de passe robustes.

2. Bases de données accessibles publiquement

Les bases de données ne sont généralement pas destinées à être accessibles directement depuis internet. Elles stockent les informations utilisées par les applications, tandis que les utilisateurs interagissent avec une interface web ou des services applicatifs.

Pourtant, il n'est pas rare d'identifier des services MySQL, MSSQL, MongoDB, Redis ou PostgreSQL accessibles publiquement. Cette situation résulte le plus souvent d'une erreur de configuration, d'une règle de pare-feu trop permissive ou d'un déploiement effectué sans restriction d'accès.

Lorsqu'une base de données est exposée, elle devient visible par tout internaute. Un attaquant peut alors tenter d'utiliser des identifiants compromis, d'exploiter une vulnérabilité connue ou de tirer parti d'une configuration insuffisamment durcie.

Comment corriger :

• Identifier les instances de bases de données accessibles depuis internet.
• Vérifier qu'aucune règle de pare-feu ou de groupe de sécurité ne les expose inutilement.
• Limiter les flux autorisés aux seuls serveurs applicatifs, réseaux d'administration ou services explicitement autorisés.
• Segmenter les environnements et isoler les bases de données dans des réseaux privés.
• Vérifier la robustesse de l'authentification, le chiffrement des communications et la mise à jour des moteurs de bases de données.

3. Services internes accessibles publiquement

Des services tels que LDAP, SNMP, NFS, Syslog ou certaines interfaces d'administration, comme l'API Docker, sont normalement réservés à des usages internes ou à des zones d'administration contrôlées.

Lorsqu'ils sont accessibles publiquement, ces services peuvent révéler des informations techniques, permettre l'énumération d'utilisateurs ou de ressources, voire donner accès à des fonctions d'administration. Leur exposition est particulièrement risquée, car ils n'ont généralement pas été conçus pour être directement accessibles depuis internet.

Comment corriger :

• Réaliser un inventaire des services accessibles depuis l'extérieur.
• Identifier les protocoles qui doivent être limités aux réseaux internes.
• Bloquer les accès publics à LDAP, SNMP, NFS, Syslog, Docker API et aux autres protocoles non destinés à une exposition externe.
• Vérifier les règles de filtrage réseau, les groupes de sécurité cloud et les configurations de pare-feu.
• Mettre en place une revue régulière des flux entrants et sortants autorisés.

Cette exposition de services internes illustre un enjeu plus large : sans cartographie fiable de ses actifs exposés, une organisation découvre souvent ces faiblesses trop tard. C'est précisément le rôle de l'External Attack Surface Management (EASM) et d'une solution telle que Security Rating : cartographier, surveiller et sécuriser en continu les actifs numériques accessibles depuis internet, qu'ils soient connus ou oubliés, comme les sous-domaines abandonnés, les environnements de test ou le shadow IT.

4. Logiciels obsolètes et CVE non corrigées

Lorsqu'une vulnérabilité est découverte, elle reçoit généralement un identifiant CVE (Common Vulnerabilities and Exposures) et fait l'objet d'une documentation publique. Les éditeurs publient ensuite des correctifs permettant de la supprimer.

Le risque apparaît lorsque ces mises à jour ne sont pas appliquées. L'attaquant n'a alors plus besoin de découvrir une faille inédite : il lui suffit d'exploiter une vulnérabilité connue, documentée et parfois déjà intégrée à des outils d'attaque largement disponibles.

La fenêtre de réaction se réduit au lieu de s'élargir. D'après le DBIR 2026 de Verizon, l'exploitation de vulnérabilités est devenue le premier vecteur d'accès initial lors des compromissions, avec 31 % des cas contre 20 % l'année précédente. Elle devance, pour la première fois en 19 ans d'existence du rapport, le vol d'identifiants, qui représente 13 % des cas.

Le rapport relève également que les organisations avaient, en moyenne, 50 % de vulnérabilités critiques supplémentaires à corriger par rapport à l'année précédente. Seules 26 % des vulnérabilités référencées dans le catalogue KEV de la CISA ont été entièrement corrigées en 2025, contre 38 % l'année précédente. Le délai médian de remédiation complète s'est par ailleurs allongé, passant de 32 à 43 jours.

Des versions vulnérables sont régulièrement observées sur des serveurs web, des équipements réseau, des applications métier ou des composants tiers intégrés aux applications.

Comment corriger :

• Établir un inventaire exhaustif des actifs, logiciels et versions déployés.
• Mettre en place un processus formalisé de gestion des correctifs.
• Prioriser les correctifs selon la criticité de la vulnérabilité, son score CVSS, sa présence éventuelle dans le catalogue KEV de la CISA et l'exposition réelle de l'actif.
• Définir des délais de remédiation cibles selon le niveau de criticité.
• Mettre en place une surveillance continue des versions détectées sur les services exposés, par exemple au moyen d'un outil d'EASM ou d'une solution de gestion des vulnérabilités.
• Suivre les exceptions de sécurité et les plans de remédiation associés lorsqu'un correctif ne peut pas être appliqué immédiatement.

5. Protocoles SSL/TLS obsolètes

Le chiffrement des communications repose aujourd'hui principalement sur TLS. Au fil du temps, plusieurs versions de SSL et TLS ont été abandonnées en raison de faiblesses cryptographiques. C'est notamment le cas de SSLv2, SSLv3, TLS 1.0 et TLS 1.1, qui ne sont plus considérés comme suffisamment sûrs.

Lorsqu'un serveur continue de les accepter, un attaquant peut tenter d'exploiter ces faiblesses connues pour dégrader le niveau de sécurité des échanges. Au-delà du risque direct, la présence de ces versions révèle souvent une pile TLS ancienne ou insuffisamment maintenue, susceptible de présenter d'autres défauts de configuration.

Comment corriger :

• Identifier les services acceptant SSLv2, SSLv3, TLS 1.0 ou TLS 1.1.
• Désactiver ces protocoles sur l'ensemble des services concernés.
• N'autoriser que TLS 1.2 au minimum et, lorsque cela est possible, TLS 1.3.
• Tester les impacts éventuels sur les applications et les clients historiques avant mise en production.
• Contrôler périodiquement la configuration TLS des services exposés conformément aux recommandations de l'ANSSI.

6. Suites de chiffrement faibles

Lors de l'établissement d'une connexion TLS, le client et le serveur négocient une suite cryptographique, ou cipher suite. Celle-ci définit les algorithmes utilisés pour le chiffrement, l'échange de clés et l'intégrité des données.

Certaines suites historiques ne sont plus considérées comme sûres : RC4, 3DES ou encore les suites dites EXPORT, conçues à une époque où des restrictions légales limitaient la robustesse du chiffrement. Un serveur qui les accepte encore expose ses communications à des attaques d'affaiblissement cryptographique et révèle souvent une configuration qui n'a pas été revue depuis longtemps.

Comment corriger :

• Réaliser un audit de la configuration TLS des services exposés.
• Désactiver les suites utilisant notamment RC4, 3DES, les chiffrements EXPORT et les algorithmes obsolètes.
• Ne conserver que les suites cryptographiques recommandées par les standards et référentiels actuels.
• Centraliser les configurations TLS dans des modèles ou bibliothèques de configuration réutilisables.
• Intégrer un contrôle régulier de ces paramètres dans les processus de déploiement et de revue de sécurité.

7. Certificats TLS invalides, expirés ou auto-signés

Les certificats TLS remplissent une double fonction : ils chiffrent les échanges et permettent de vérifier l'identité du serveur auquel un utilisateur se connecte. Lorsqu'un certificat est expiré, auto-signé ou ne correspond pas au nom de domaine utilisé, cette vérification n'est plus assurée et les navigateurs affichent des avertissements de sécurité.

Au-delà de l'impact sur la confiance des utilisateurs, ces erreurs compliquent la détection de véritables tentatives d'usurpation. Un utilisateur habitué à ignorer les alertes de certificat sera plus enclin à accepter une connexion malveillante.

Comment corriger :

• Recenser les certificats utilisés par les services exposés.
• Automatiser leur renouvellement, notamment via le protocole ACME lorsque cela est possible.
• Mettre en place des alertes en amont des dates d'expiration.
• Vérifier la validité de la chaîne de certification et la correspondance entre le certificat et les noms de domaine utilisés.
• Retirer les certificats auto-signés des services publics, sauf cas d'usage strictement maîtrisé et justifié.

8. Headers de sécurité HTTP manquants ou mal configurés

Les headers de sécurité HTTP figurent parmi les constats les plus fréquents lors des évaluations de sécurité. Leur mise en place ne nécessite pourtant, dans la plupart des cas, que quelques lignes de configuration sur le serveur web, le proxy inverse ou la passerelle applicative.

Une réponse HTTP ne contient pas uniquement le contenu d'une page web. Le serveur envoie également des en-têtes qui indiquent au navigateur quelles protections appliquer. Parmi les plus importants, Content-Security-Policy (CSP) contrôle les ressources que le navigateur peut exécuter et limite les possibilités d'exploitation d'une faille XSS. Strict-Transport-Security (HSTS) impose l'usage systématique de HTTPS et rend plus difficiles les attaques d'interception ou de dégradation des communications.

L'absence de ces protections ne constitue pas nécessairement une vulnérabilité critique à elle seule, mais elle prive le navigateur de mécanismes de défense utiles et augmente la surface d'attaque applicative.

Comment corriger :

• Identifier les applications web exposées ne renvoyant pas les en-têtes de sécurité essentiels.
• Déployer progressivement CSP, HSTS, X-Content-Type-Options et X-Frame-Options.
• Tester les politiques CSP en mode rapport avant de les appliquer de manière bloquante.
• Configurer les en-têtes au niveau des composants mutualisés, comme les CDN, WAF, proxys inverses ou serveurs web.
• Intégrer leur vérification aux contrôles de sécurité réalisés avant chaque mise en production.

9. SPF, DKIM et DMARC absents ou mal configurés

SPF, DKIM et DMARC sont trois mécanismes complémentaires destinés à lutter contre l'usurpation d'identité par email.

SPF permet à un domaine de déclarer quels serveurs sont autorisés à envoyer des emails en son nom. DKIM ajoute une signature cryptographique qui permet de vérifier que le message n'a pas été modifié en transit et qu'il provient bien du domaine émetteur. DMARC complète l'ensemble en vérifiant l'alignement entre le domaine visible par l'utilisateur et ceux utilisés par SPF et DKIM. Il indique également l'action à appliquer en cas d'échec : ne rien faire (p=none), mettre en quarantaine (p=quarantine) ou rejeter (p=reject).

Dans les exercices de notation cyber, il est fréquent de constater l'absence de SPF, des configurations incomplètes ou des politiques DMARC limitées à p=none. Les mécanismes existent alors sur le papier, mais leur efficacité reste réduite. Cette faiblesse ne permet pas de compromettre directement un système, mais elle facilite les campagnes de phishing usurpant le domaine de l'entreprise, y compris auprès de ses clients et de ses fournisseurs.

Comment corriger :

• Recenser tous les services légitimes autorisés à envoyer des emails au nom du domaine.
• Déployer un enregistrement SPF strict et éviter les autorisations trop larges.
• Activer DKIM sur les plateformes de messagerie, outils marketing et services tiers concernés.
• Mettre en place DMARC en p=none pour analyser les rapports et identifier les flux légitimes.
• Faire évoluer progressivement la politique vers p=quarantine, puis p=reject, une fois les flux légitimes validés.
• Suivre régulièrement les rapports DMARC afin d'identifier les tentatives d'usurpation et les anomalies de configuration.

10. DNSSEC non déployé et Wildcard DNS

Le DNS joue un rôle essentiel sur internet en associant un nom de domaine à une adresse IP. DNSSEC permet de signer cryptographiquement les réponses DNS afin que les résolveurs puissent en vérifier l'authenticité et l'intégrité. Sans ce mécanisme, certaines manipulations de réponses DNS entre l'utilisateur et le serveur sont plus difficiles à détecter.

Autre observation fréquente lors des audits : la présence d'enregistrements Wildcard DNS. Un enregistrement wildcard permet de répondre aux requêtes portant sur des sous-domaines qui n'ont pas été définis explicitement. Cette pratique peut être légitime dans certains contextes, mais elle complique l'identification des actifs réellement exposés et peut masquer des erreurs de configuration ou des sous-domaines oubliés.

Comment corriger :

• Vérifier la compatibilité des domaines, registrars et prestataires DNS avec DNSSEC.
• Déployer DNSSEC sur les domaines de l'organisation et contrôler régulièrement la validité de la chaîne de signature.
• Maintenir un inventaire à jour des zones DNS, sous-domaines et enregistrements associés.
• Identifier les enregistrements wildcard existants et documenter leur justification métier.
• Supprimer ou restreindre les wildcard DNS qui ne répondent pas à un besoin identifié.
• Vérifier régulièrement que les sous-domaines renvoyés par le DNS correspondent à des actifs réellement maîtrisés.

Des faiblesses révélatrices de la maturité cyber, y compris chez vos fournisseurs

Toutes ces vulnérabilités ont un point commun : elles résultent rarement de techniques d'attaque avancées. Dans la plupart des cas observés par Security Rating, elles sont liées à des erreurs de configuration, à des mécanismes de sécurité absents ou à des technologies qui n'ont pas été maintenues dans le temps.

Prises individuellement, elles peuvent sembler limitées. Cumulées, elles augmentent significativement la surface d'attaque externe d'une organisation et traduisent un manque de maîtrise de ses actifs exposés, de ses configurations et de ses processus de maintenance.

Cette lecture vaut pour votre organisation, mais également pour l'ensemble de votre écosystème. Le DBIR 2026 de Verizon relève que la part des compromissions impliquant un tiers a progressé de 60 % en un an, pour atteindre 48 % du total des compromissions analysées. Le rapport observe aussi que seules 23 % des organisations tierces ayant une exposition cloud avaient entièrement corrigé une authentification multifacteur absente ou mal sécurisée.

Selon l'Observatoire TPRM 2025 mené par le CESIN et Board of Cyber auprès de plus de 170 organisations, 82 % des répondants considèrent désormais le risque cyber fournisseur comme important ou très important.

Ces 10 vulnérabilités présentent une caractéristique précieuse : elles sont observables depuis l'extérieur, sans intrusion dans le système d'information. Elles constituent donc des indicateurs objectifs et mesurables de la maturité cyber d'un tiers, directement exploitables dans un programme de gestion des risques fournisseurs.

Elles complètent utilement les questionnaires déclaratifs, dont les limites peuvent compromettre une stratégie de gestion des risques tiers. Elles peuvent également alimenter des exigences concrètes de remédiation au travers des clauses contractuelles de sécurité. Des réglementations comme NIS2 ou DORA imposent d'ailleurs une surveillance renforcée de la chaîne d'approvisionnement numérique.

Pour structurer cette démarche, découvrez les étapes clés d'un projet de TPRM.

Cette analyse externe s'inscrit naturellement parmi les 7 méthodes pour évaluer le risque cyber de vos fournisseurs, aux côtés des questionnaires déclaratifs ou des certifications. Elle peut également nourrir les questions qu'un RSSI doit poser à ses fournisseurs SaaS lors d'une campagne d'audit et compléter une démarche de due diligence fournisseur en amont de la contractualisation.

Une certification telle qu'ISO 27001 atteste de l'existence d'un système de management de la sécurité de l'information. Elle ne garantit toutefois pas, à elle seule, l'absence de vulnérabilités techniques sur le périmètre réellement exposé. Les deux approches sont complémentaires, non substituables.

Détecter et corriger ces vulnérabilités avec Security Rating

Les 10 vulnérabilités décrites dans cet article font partie des points de contrôle analysés par Security Rating, la solution de notation cyber de Board of Cyber.

Entièrement automatisée et non intrusive, Security Rating identifie, classe et analyse les actifs publiquement accessibles d'une organisation, notamment ses adresses IP, URL et noms de domaine. La solution permet d'identifier les expositions techniques, les configurations à risque et les versions vulnérables afin de prioriser les actions de remédiation.

Security Rating attribue un score de maturité cyber de 0 à 1 000, mis à jour en continu, et fournit des recommandations concrètes pour chaque domaine d'analyse. Le benchmark sectoriel permet de se situer par rapport à des organisations comparables, tandis que la vue multi-organisations facilite l'évaluation simultanée d'un portefeuille de fournisseurs ou de filiales.

Vous souhaitez connaître votre niveau d'exposition externe ou évaluer celui de vos fournisseurs ? Demandez une démo pour visualiser les vulnérabilités détectées, suivre leur remédiation et piloter votre risque cyber dans la durée.

Conclusion : la sécurité repose sur l'accumulation de bonnes pratiques

Corriger ces faiblesses ne nécessite pas toujours des projets complexes ou des investissements importants. Cela demande avant tout une bonne maîtrise de sa surface exposée, de ses configurations et de ses processus de mise à jour.

La sécurité ne dépend pas d'une mesure unique, mais de l'accumulation de bonnes pratiques appliquées avec constance. Chaque vulnérabilité corrigée représente une opportunité en moins pour un attaquant.

C'est également un signal de confiance adressé à vos clients, partenaires, fournisseurs, assureurs et régulateurs. Votre surface d'attaque externe est observable : sa maîtrise témoigne directement de votre niveau de maturité cyber.

FAQ

Quelles sont les vulnérabilités les plus fréquentes détectées lors d'une évaluation de sécurité ?

Les constats les plus récurrents concernent les services d'administration et les bases de données accessibles publiquement, les logiciels obsolètes présentant des CVE connues, les configurations TLS anciennes, les certificats invalides, les headers de sécurité HTTP manquants, les protections email incomplètes et l'absence de DNSSEC. Ces vulnérabilités résultent le plus souvent d'erreurs de configuration ou d'un défaut de maintenance, plutôt que de techniques d'attaque sophistiquées.

Pourquoi ces vulnérabilités persistent-elles alors qu'elles sont connues ?

Elles persistent principalement en raison d'un manque de visibilité sur la surface réellement exposée, par exemple à cause du shadow IT, de sous-domaines oubliés ou de services déployés sans validation. Des processus de mise à jour incomplets et la difficulté à prioriser un volume croissant de correctifs jouent également un rôle important. Sans inventaire fiable ni surveillance continue, ces faiblesses peuvent passer inaperçues jusqu'à un audit ou un incident.

Comment détecter ces vulnérabilités sans scanner intrusif ?

Les vulnérabilités décrites dans cet article sont observables depuis l'extérieur, à partir des actifs publics de l'organisation. C'est le principe de la notation cyber, mise en œuvre par une solution telle que Security Rating : une analyse non intrusive et continue de la surface d'attaque externe, qui produit un score de maturité ainsi que des recommandations de remédiation, sans pénétrer le système d'information.

Ces vulnérabilités concernent-elles aussi mes fournisseurs ?

Oui, et c'est un enjeu majeur. Selon le DBIR 2026 de Verizon, la part des compromissions impliquant un tiers a progressé de 60 % en un an pour atteindre 48 % du total des compromissions analysées. Parce qu'elles sont observables de l'extérieur, ces vulnérabilités constituent des indicateurs objectifs pour évaluer la posture cyber des tiers et alimenter un programme TPRM, en complément des questionnaires déclaratifs et des clauses contractuelles de sécurité.