5 Menaces Cybersécurité qui Ciblent les Sites Web d'Entreprise en 2025

1. Injections SQL et injections NoSQL — la faille qui ne pardonne pas

L'injection SQL figure au sommet du classement OWASP Top 10 depuis 2003, et elle reste en 2025 l'une des vulnérabilités les plus exploitées sur les sites web d'entreprise. Le principe est simple : un attaquant injecte du code SQL malveillant dans un champ de formulaire ou un paramètre d'URL pour manipuler la base de données sous-jacente. Les conséquences vont de l'extraction massive de données clients (mots de passe, coordonnées bancaires, données de santé) à la destruction complète de la base, en passant par une prise de contrôle totale du serveur.

En 2025, les injections SQL automatisées se sont perfectionnées. Des outils comme SQLMap, désormais accessibles à des profils peu techniques, scannent en quelques secondes des milliers de paramètres d'URL sur votre site à la recherche du moindre point d'entrée non sécurisé. Plus inquiétant encore, les applications utilisant des bases NoSQL comme MongoDB ou Firebase ne sont pas à l'abri : les injections NoSQL ciblent les opérateurs de requêtes ($where, $gt, $regex) avec la même efficacité dévastatrice.

Comment s'en protéger

• ● Requêtes paramétrées systématiques : toute interaction avec la base de données doit utiliser des prepared statements. Aucune concaténation de chaîne directe avec des données utilisateur n'est acceptable.
• ● WAF applicatif en amont avec règles OWASP CRS activées — Cloudflare WAF, ModSecurity ou AWS WAF filtrent la quasi-totalité des tentatives automatisées connues.
• ● Principe du moindre privilège en base de données : le compte utilisé par votre application web ne doit jamais avoir les droits DROP, ALTER ou l'accès à d'autres tables que celles strictement nécessaires.
• ● Audit de code source annuel avec un outil SAST (Semgrep, Checkmarx) pour identifier les points d'injection non protégés dans votre code.

2. Cross-Site Scripting stocké — quand votre site devient l'arme

Le Cross-Site Scripting (XSS) stocké est une vulnérabilité qui survient lorsque du contenu malveillant injecté par un attaquant est enregistré de façon permanente dans votre base de données, puis renvoyé tel quel à chaque visiteur. Contrairement au XSS réfléchi (qui nécessite que la victime clique sur un lien piégé), le XSS stocké transforme votre propre site en vecteur d'attaque autonome : chaque visiteur qui consulte une page compromis exécute involontairement le code malveillant dans son navigateur.

En 2025, les attaques XSS stockées visent en priorité les commentaires de blogs, les formulaires de support client, les champs de profil utilisateur et les systèmes de messagerie interne. Le code injecté peut voler les cookies de session des administrateurs (et donc prendre le contrôle de votre back-office), rediriger silencieusement certains visiteurs vers des pages de phishing, injecter un skimmer de carte bancaire sur vos pages de paiement, ou recruter les navigateurs de vos visiteurs dans un botnet.

Comment s'en protéger

• ● Encodage systématique des sorties : toute donnée provenant d'un utilisateur doit être encodée (HTML entities) avant d'être affichée dans une page web. Les frameworks modernes (React, Vue, Angular) font cela automatiquement — à condition de ne pas utiliser dangerouslySetInnerHTML ou équivalents.
• ● Content Security Policy (CSP) stricte : un header CSP correctement configuré empêche l'exécution de scripts non autorisés, y compris ceux injectés par XSS. C'est l'un des contrôles les plus efficaces et les moins déployés.
• ● Validation côté serveur de tous les champs acceptant du texte libre — jamais uniquement côté client (JavaScript) car un attaquant peut contourner la validation navigateur.
• ● Cookie HttpOnly + Secure + SameSite=Strict pour tous les cookies de session : même si un script XSS s'exécute, il ne peut pas accéder aux cookies de session.

3. Credential stuffing — le vol silencieux de comptes clients

Le credential stuffing n'est pas une attaque qui exploite une vulnérabilité dans votre code : c'est une attaque qui exploite le comportement humain. Des milliards de paires login/mot de passe volées lors de fuites de données antérieures (LinkedIn 2012, Adobe 2013, Facebook 2019, et des milliers d'autres incidents depuis) circulent librement sur les forums clandestins. Les attaquants utilisent des outils automatisés pour tester ces combinaisons — à grande vitesse et depuis des milliers d'adresses IP différentes — sur les pages de connexion de votre site.

En 2025, les campagnes de credential stuffing ont fortement progressé, portées par la démocratisation des services CAPTCHA-solving et des proxies résidentiels. Si 70 % de vos utilisateurs réutilisent leurs mots de passe sur plusieurs services (c'est la moyenne française selon CNIL/ANSSI), une fraction significative de leurs comptes sur votre plateforme peut être compromise sans que vous en ayez la moindre alerte. L'attaquant entre discrètement, copie les données, et repart — parfois en revendant l'accès à un tiers avant même de l'utiliser lui-même.

Comment s'en protéger

• ● Authentification multi-facteurs (MFA) obligatoire sur tous les comptes à accès sensible. L'OTP par email ou application TOTP suffit pour bloquer 99,9 % des tentatives de credential stuffing, même avec des identifiants valides.
• ● Détection des anomalies de connexion : limitez les tentatives par IP et par compte (rate limiting), et alertez sur les connexions depuis des géolocalisations inhabituelles ou des combinaisons IP/navigateur jamais vues.
• ● Vérification des mots de passe compromis lors de l'inscription et du changement de mot de passe — l'API Have I Been Pwned (k-anonymity) permet de vérifier si un mot de passe figure dans des bases de données volées sans envoyer le mot de passe en clair.
• ● CAPTCHA adaptatif (Turnstile, hCaptcha) sur les pages de connexion avec comportement suspect, sans frictionner les connexions légitimes.

4. Détournement de CDN et supply chain web — la menace invisible

Les attaques sur la supply chain web représentent en 2025 l'une des menaces les plus sophistiquées et les plus sous-estimées par les entreprises de taille moyenne. Votre site charge probablement des scripts externes depuis des CDN tiers : Google Analytics, des bibliothèques JavaScript populaires, des widgets de chat, des outils de paiement, des polices de caractères. Si l'un de ces fournisseurs est compromis, ou si vous référencez un package npm malveillant, du code hostile peut s'exécuter sur votre site — et sur les navigateurs de tous vos visiteurs — sans que vous ayez touché une seule ligne de votre propre code.

L'incident Polyfill.io de juin 2024 reste l'illustration la plus saisissante : un service CDN rachetée par une entreprise chinoise a injecté du code malveillant dans un script chargé par plus de 100 000 sites web dans le monde. Des milliers d'entreprises françaises ont été affectées sans le savoir. En 2025, des campagnes similaires ciblent des modules npm abandonnés dont les noms ressemblent à des packages populaires (typosquatting).

Comment s'en protéger

• ● Subresource Integrity (SRI) : chaque script externe chargé via une balise <script> doit inclure un attribut integrity contenant le hash SHA-256 du fichier. Si le fichier est modifié côté CDN, le navigateur refusera de l'exécuter.
• ● Auto-hébergement des ressources critiques : les bibliothèques JavaScript essentielles à votre fonctionnement devraient idéalement être hébergées sur votre propre infrastructure, avec un processus de mise à jour contrôlé.
• ● Audit régulier des dépendances avec des outils comme npm audit, Snyk ou Dependabot — et suppression systématique des packages non utilisés (surface d'attaque réduite).
• ● Monitoring en temps réel de toutes les requêtes sortantes de votre site — une ressource externe nouvelle ou modifiée doit déclencher une alerte.

5. Attaques sur les API REST — la surface exposée que vous ignorez

La quasi-totalité des sites web modernes repose sur des API REST pour faire communiquer le front-end avec le back-end, intégrer des services tiers ou exposer des données à des applications mobiles. En 2025, les API sont devenues la principale surface d'attaque des applications web, dépassant pour la première fois les vulnérabilités de l'interface visible (Gartner, rapport "API Security Landscape 2025"). La raison est simple : les équipes de développement se concentrent sur la sécurité de ce que l'utilisateur voit, et négligent l'API qui alimente l'ensemble.

Les vecteurs d'attaque les plus fréquents en 2025 sont l'Excessive Data Exposure (l'API renvoie plus de données que ce que l'interface affiche — un attaquant qui analyse les réponses JSON peut accéder à des champs sensibles), le BOLA/IDOR (Broken Object Level Authorization — en changeant l'identifiant dans l'URL /api/users/1234/orders, un attaquant accède aux commandes d'un autre utilisateur), et les API shadow ou zombie (des endpoints créés en développement, jamais supprimés, sans authentification et totalement oubliés de la documentation).

Comment s'en protéger

• ● Inventaire complet de toutes vos API : vous ne pouvez pas sécuriser ce que vous ne connaissez pas. Un outil de découverte d'API (Salt Security, Noname) ou un audit manuel exhaustif doit précéder toute démarche de sécurisation.
• ● Authentification et autorisation strictes à chaque endpoint : chaque requête API doit vérifier que l'utilisateur authentifié a bien le droit d'accéder à la ressource demandée (pas seulement que le token est valide).
• ● Réponses minimales : votre API ne doit retourner que les champs strictement nécessaires à l'interface — jamais des objets complets incluant des champs internes comme les hash de mots de passe, les identifiants internes ou les métadonnées techniques.
• ● Rate limiting et monitoring comportemental sur toutes les routes : une API légitime n'est pas interrogée 10 000 fois par minute depuis la même adresse IP.

Plan d'action prioritaire : par où commencer ?

Face à ces cinq menaces, la tentation est de vouloir tout traiter simultanément. C'est contre-productif : mieux vaut prioriser par impact et par faisabilité. Voici un plan en trois étapes réaliste pour une PME sans équipe sécurité dédiée.

La sécurité web n'est pas un état qu'on atteint une fois pour toutes : c'est un processus continu d'évaluation et d'amélioration. Les attaquants évoluent ; vos défenses doivent évoluer avec eux. Le vrai retour sur investissement de la cybersécurité ne se mesure pas en fonctionnalités débloquées, mais en incidents évités — et en confiance maintenue auprès de vos clients, partenaires et régulateurs.

FAQ