TPE, PME, attention : les failles qui vous coûtent le plus cher sont aussi les plus banales

Les cyberattaques les plus douloureuses pour les entreprises ne reposent pas toujours sur des techniques d’élite, loin de là. Très souvent, elles exploitent des faiblesses basiques, parfaitement connues, documentées depuis des années, mais qui continuent de circuler dans les sites, les API et les outils sur mesure que les TPE et PME utilisent tous les jours.

MITRE vient de publier la nouvelle édition de son Top 25 des faiblesses logicielles les plus dangereuses. Derrière ce nom un peu abstrait, on trouve une organisation américaine à but non lucratif qui travaille depuis des années avec les pouvoirs publics pour structurer tout ce qui touche à la sécurité des logiciels. C’est elle qui maintient le référentiel CWE et gère le programme CVE, deux bases qui aident à décrire les failles de manière cohérente d’un éditeur à l’autre. Autrement dit, c’est une photographie assez fidèle des erreurs qui font le plus mal aux entreprises.

Pour ce cru 2025, MITRE s’appuie sur 39 080 enregistrements CVE publiés entre le 1er juin 2024 et le 1er juin 2025, afin de mesurer à la fois la fréquence et la gravité de chaque type de problème. Le résultat tient en un palmarès qui ne parle pas seulement aux experts, mais à toutes les entreprises qui s’appuient sur des applications web, des API et des outils métier.

Pour les TPE et les PME, ce classement rappelle surtout que les attaques les plus pénibles ne commencent pas forcément par une vulnérabilité rare, mais par des erreurs très ordinaires, héritées d’un développement trop rapide, d’un vieux module conservé par habitude ou d’un back-office jamais vraiment audité. Injection SQL, XSS et problèmes de droits d’accès dominent ce classement 2025, et résument à eux seuls une bonne partie des incidents qui finissent en fuite de données, en arrêt d’activité… et en addition salée.

Le XSS, l’erreur qui transforme une page en piège

Le XSS a une réputation presque trompeuse, parce qu’on le réduit souvent à une démonstration inoffensive dans un navigateur. En production, c’est autre chose. Il suffit qu’un site réaffiche une donnée non fiable sans l’encoder correctement, c'est-à-dire sans la transformer en texte simple, pour que le navigateur interprète cette donnée comme du code. À partir de là, un attaquant peut modifier ce que la victime voit, injecter une fausse interface, forcer une redirection vers une page frauduleuse, récupérer des infos affichées dans l’espace client, parfois même détourner une session déjà ouverte.

Et c’est justement ce qui le rend si pénible pour les petites structures. Le XSS adore les zones « vivantes » d’un site, à savoir les champs dans lesquels on saisit un nom, un commentaire, un message, un ticket support, un libellé de commande, une recherche. Tout ce qui est pratique pour vos clientes et clients est aussi un point d’entrée pour les attaques si l’application ne traite pas strictement ce qu’elle accepte et la manière dont elle le réaffiche.

Ici, le correctif tient à une règle qui ne se négocie pas. Toute donnée externe doit être traitée comme du texte. Et surtout, ce traitement doit être fait selon l’endroit où la donnée finit, dans le HTML, dans un attribut, dans une URL, dans un fragment JavaScript. Si vous autorisez du contenu mis en forme, par exemple des commentaires avec liens ou des textes copiés depuis un éditeur riche, il faut limiter strictement ce qui est accepté et nettoyer ces contenus avant affichage.

Et si votre prestataire vous répond « tout va bien, on a un WAF » (pare-feu applicatif web), vous pouvez lui rappeler que ce n’est qu’un filet de sécurité, pas une correction, et ramener la discussion au vrai sujet, à savoir comment l’encodage est géré, comment la partie visible du site limite les injections, et comment les tests empêchent les régressions au fil des mises à jour.

L’injection SQL, le grand classique qui refuse de mourir

L’injection SQL, tout le monde en a entendu parler, et elle continue pourtant de faire des dégâts. L’application envoie à la base des requêtes qui mélangent des instructions et des données issues d’un formulaire, d’une API ou d’un service externe. Si la séparation n’est pas garantie, la base peut exécuter autre chose que ce qui était prévu, et permettre l’accès à des données, leur modification, leur suppression, ou préparer le terrain pour une intrusion plus profonde.

Dans une TPE ou une PME, l’impact est souvent disproportionné, parce que les bases fourre-tout regroupent les clientes et clients, la facturation, les commandes, les produits, parfois des données partenaires. Une faille dans un formulaire, une API interne ou un outil d’administration peut donc ouvrir un accès à bien plus que ce que l’écran laisse deviner.

La bonne nouvelle, c’est que les parades sont connues depuis longtemps. Requêtes paramétrées partout, c’est-à-dire des requêtes où les valeurs issues des formulaires sont envoyées séparément, sans être collées dans la chaîne SQL à coups de guillemets, y compris pour les requêtes construites dynamiquement quand elles intègrent des filtres ou des critères variables, audit prioritaire de tout ce qui dialogue avec la base, et droits techniques limités au strict nécessaire, idéalement avec des comptes séparés selon les usages. Et pour éviter la sortie de route classique, vous pouvez, là aussi, demander à votre prestataire quels contrôles sont en place, comment ils sont testés, et comment le prestataire évite les retours en arrière lors des mises à jour.

Les droits d’accès, la fuite qui ressemble à une fonction

Il existe enfin une catégorie encore plus sournoise, parce qu’elle ne fait pas de bruit. L’utilisateur est connecté, la session est valide, mais l’application ne vérifie pas systématiquement que cette personne a le droit d’accéder à tel document, tel compte, telle commande, telle facture. Il suffit alors de changer une référence dans une requête, dans une URL, dans un paramètre d’API, pour tomber sur les données de quelqu’un d’autre.

C’est un grand classique des outils empilés au fil du temps, un portail partenaire ajouté un jour, un back-office étendu le mois suivant, une API montée pour relier deux logiciels, un module repris par un autre prestataire. Tant que personne ne teste la logique de droits comme le ferait un attaquant, le bug peut passer pour une fonctionnalité.

Dans ce cas, tout repose sur la discipline, parce qu’il n’existe pas de solution miracle capable de rattraper une logique d’autorisations mal tenue. Il faut vérifier les droits côté serveur, à chaque accès, sur chaque ressource, et considérer qu’une demande venant du front n’est jamais une preuve en soi, même quand la personne est déjà connectée. Pour éviter l’accumulation d’exceptions au fil des évolutions, des règles simples et stables, appliquées partout de la même façon, font souvent gagner plus de sécurité qu’une logique de permissions raffinée mais incohérente d’un module à l’autre.

Ce qu’une petite structure peut faire, sans se noyer

Le top 25 de MITRE peut donner envie de tout revoir, tout de suite. Mauvaise idée. Une petite structure n’a ni le temps ni les moyens de traiter cinquante sujets en parallèle, et la sécurité n’y gagne rien si elle se transforme en chantier interminable.

Ce classement est utile quand on s’en sert pour remettre de l’ordre. On commence par repérer les parcours qui brassent des données sensibles et les fonctions qui font gagner du temps au quotidien, parce que ce sont souvent les mêmes. Un formulaire de contact, une recherche, un espace client, une API, un export comptable, un back-office. C’est là que les erreurs ordinaires s’accumulent et que les attaques les plus rentables trouvent leur chemin.

Le bon usage consiste donc à définir quelques règles simples et non négociables, puis à vérifier qu’elles existent vraiment dans le code avec vos équipes ou votre prestataire. Concrètement, les données saisies dans les formulaires sont toujours traitées comme du texte avant affichage et ne sont jamais réutilisées comme du code. Les requêtes SQL sont construites avec des paramètres, les valeurs étant transmises séparément plutôt qu’injectées directement dans une chaîne. Les droits d’accès, eux, ne sont pas supposés du simple fait qu’une personne est connectée, mais vérifiés côté serveur à chaque action importante. Une fois ces principes devenus réalité technique, vous avez déjà coupé l’herbe sous le pied à nombre d’incidents avant même qu'ils se produisent.

En bref, le top 25 ne vous apprend pas de nouveaux risques. Il vous rappelle que les plus chers sont souvent les plus routiniers, et qu’ils s’installent surtout quand on confond vitesse de livraison et absence de garde-fous.