Sécuriser une application web : 10 failles que ton site a probablement

La majorité des sites web de PME ont au moins trois failles de sécurité exploitables — et leurs propriétaires n'en savent rien.

C'est ce qu'on constate chez CZMultimedia quand on audite des applications web avant refonte ou mise en production. Pas des failles théoriques. Des portes ouvertes, concrètes, que n'importe quel script automatisé peut exploiter en quelques minutes.

Le problème n'est pas que la sécurité soit complexe. C'est qu'elle est systématiquement repoussée à "plus tard" — et que "plus tard" arrive généralement sous la forme d'un email de ton hébergeur qui te dit que ton site distribue du malware.

Pour un cadrage sécurité sur ton projet : Contactez-nous

Sommaire

• Pourquoi la sécurité est le parent pauvre des projets web PME
• Les 10 failles les plus courantes
• Comment vérifier si ton site est concerné
• Cas terrain : site e-commerce piraté et remédiation
• Plan d'action sécurité en 5 étapes
• Checklist sécurité
• FAQ

Pourquoi la sécurité est le parent pauvre des projets web PME

Quand un dirigeant lance un projet web, le budget se répartit entre le design, le développement et le contenu. La sécurité ? Elle n'apparaît même pas dans le cahier des charges. On la considère "incluse" — sans qu'aucune ligne de budget ni aucun temps ne lui soit alloué.

Résultat : d'après le rapport 2025 de Verizon sur les Data Breaches, 43 % des cyberattaques ciblent des petites entreprises. Et selon l'ANSSI (Agence nationale de la sécurité des systèmes d'information), le nombre d'incidents traités a augmenté de 30 % entre 2023 et 2025 pour les PME françaises.

Trois raisons expliquent ce décalage :

1. L'illusion du "trop petit pour être ciblé". Les attaques ne sont pas manuelles. Ce sont des bots qui scannent des millions d'adresses à la recherche de vulnérabilités connues. Ton site de 15 pages est aussi visible qu'un site de 15 000 pages si la porte est ouverte.

2. La dette technique invisible. Un CMS installé il y a trois ans avec des plugins jamais mis à jour, c'est l'équivalent d'une serrure rouillée sur une porte vitrée. Le site "fonctionne" — mais il est ouvert.

3. Le faux sentiment de sécurité HTTPS. Avoir un certificat SSL (le cadenas vert dans le navigateur), c'est indispensable. Mais ça ne protège que le transport des données. Pas le site lui-même.

Si ton site a aussi des problèmes de performance et de temps de chargement, c'est souvent le signe d'une dette technique plus large qui touche aussi la sécurité.

Les 10 failles les plus courantes

Cette liste s'inspire du OWASP Top 10 (dernière mise à jour 2021, référence mondiale en sécurité applicative), vulgarisée et adaptée à ce qu'on observe concrètement sur les sites de PME.

Faille 1 — Injection SQL

Le principe : un attaquant envoie du code SQL via un champ de formulaire (recherche, login, contact) et accède à ta base de données.

En pratique : si ton formulaire de recherche n'est pas protégé, quelqu'un peut taper ' OR 1=1 -- dans le champ et récupérer l'intégralité de ta table utilisateurs — mots de passe inclus.

Qui est concerné : tout site avec une base de données et des formulaires. WordPress avec certains plugins mal codés, applications sur mesure sans requêtes préparées (prepared statements).

La correction : utiliser des requêtes paramétrées. Jamais de concaténation de chaînes dans les requêtes SQL. C'est une règle de base que tout framework moderne applique par défaut — à condition de l'utiliser correctement.

Faille 2 — Cross-Site Scripting (XSS)

Le principe : un attaquant injecte du JavaScript malveillant dans une page que d'autres utilisateurs vont consulter.

En pratique : un commentaire sur ton blog, un champ de profil, un paramètre d'URL — si le contenu n'est pas échappé (sanitized), le script s'exécute dans le navigateur de chaque visiteur. L'attaquant peut voler des cookies de session, rediriger vers un site de phishing, ou afficher un faux formulaire de connexion.

La correction : échapper systématiquement toutes les sorties HTML. Mettre en place une Content Security Policy (CSP) stricte via les headers HTTP.

Faille 3 — Authentification cassée

Le principe : mots de passe faibles autorisés, pas de limite de tentatives de connexion, tokens de session prévisibles.

En pratique : sans rate limiting sur ta page de login, un bot teste des milliers de combinaisons par minute (brute force). Si tes utilisateurs utilisent "123456" comme mot de passe (encore le plus fréquent en France selon NordPass 2025), le compte tombe en quelques secondes.

La correction : imposer des mots de passe robustes (12 caractères minimum, mixte), mettre en place un rate limiting (max 5 tentatives par minute), proposer l'authentification à deux facteurs (2FA).

Faille 4 — Exposition de données sensibles

Le principe : des informations confidentielles sont accessibles sans protection — dans le code source, dans des fichiers publics, ou transmises sans chiffrement.

En pratique : on a vu des clés API Stripe en clair dans du JavaScript côté client, des fichiers .env accessibles via l'URL, des backups de base de données dans le dossier /public/. Ce sont des erreurs de configuration, pas des attaques sophistiquées.

La correction : ne jamais stocker de secrets côté client. Vérifier que les fichiers sensibles (.env, .git/, backups) ne sont pas accessibles via le web. Chiffrer les données sensibles en base.

Faille 5 — Contrôle d'accès défaillant

Le principe : un utilisateur peut accéder à des ressources ou des actions qui ne lui sont pas destinées.

En pratique : tu es connecté en tant que client, tu changes l'ID dans l'URL (/commande/123 → /commande/124) et tu vois la commande de quelqu'un d'autre. Ou bien un utilisateur standard accède au panel admin en tapant directement /admin.

La correction : vérifier les autorisations côté serveur pour chaque requête. Ne jamais se fier uniquement au fait qu'un bouton est masqué côté client — si l'URL est accessible, elle sera trouvée.

Faille 6 — Mauvaise configuration de sécurité

Le principe : le serveur, le framework ou le CMS utilise des paramètres par défaut non sécurisés.

En pratique : page d'erreur qui affiche la stack trace complète (versions du serveur, chemins de fichiers), headers HTTP manquants (pas de X-Frame-Options, pas de Content-Security-Policy), répertoire /admin accessible sans IP whitelisting.

La correction : supprimer les pages par défaut, désactiver le mode debug en production, configurer tous les headers de sécurité, limiter l'accès aux interfaces d'administration.

Faille 7 — Cross-Site Request Forgery (CSRF)

Le principe : un attaquant force un utilisateur authentifié à exécuter une action à son insu (changer son email, valider un paiement).

En pratique : tu es connecté à ton site bancaire. Tu cliques sur un lien dans un email. Ce lien déclenche une requête vers ta banque en utilisant ta session active. Sans protection CSRF, la requête passe.

La correction : générer un token CSRF unique par session et le vérifier à chaque requête sensible. Tous les frameworks modernes (Symfony, Laravel, Nuxt) intègrent cette protection — il faut juste l'activer.

Faille 8 — Composants vulnérables

Le principe : des librairies, plugins ou dépendances avec des failles connues sont utilisés sans mise à jour.

En pratique : un plugin WordPress avec une faille CVE publiée depuis 6 mois, une version de jQuery avec une vulnérabilité XSS connue, un package npm avec une backdoor. Ce sont des failles documentées, avec des exploits disponibles publiquement.

La correction : mettre à jour régulièrement toutes les dépendances. Utiliser npm audit ou pnpm audit pour le JavaScript, composer audit pour PHP. Configurer Dependabot ou Renovate pour les alertes automatiques.

Contactez-nous si tu as un doute sur la sécurité de ton site — on te fait un diagnostic honnête en 48h.

Faille 9 — Logging et monitoring insuffisants

Le principe : aucune trace des tentatives d'attaque, aucune alerte en cas de comportement anormal.

En pratique : un attaquant teste des injections SQL pendant trois semaines sur ton formulaire de login. Sans logs centralisés ni monitoring, tu ne le sais jamais — jusqu'à ce que les données soient exfiltrées.

La correction : logger toutes les tentatives d'authentification (réussies et échouées), les erreurs serveur, les accès aux ressources sensibles. Configurer des alertes sur les seuils anormaux (ex. : plus de 50 erreurs 401 par heure).

Faille 10 — Server-Side Request Forgery (SSRF)

Le principe : un attaquant manipule une fonctionnalité du serveur pour qu'il envoie des requêtes vers des ressources internes.

En pratique : ton site a une fonction "aperçu d'URL" ou "import d'image depuis une URL". Un attaquant fournit une URL comme http://localhost:8080/admin ou http://169.254.169.254/ (endpoint de métadonnées AWS) et ton serveur effectue la requête avec ses propres accès réseau.

La correction : valider et filtrer toutes les URLs fournies par l'utilisateur. Bloquer les requêtes vers des adresses internes (localhost, IPs privées). Utiliser une allowlist d'hôtes autorisés quand c'est possible.

Comment vérifier si ton site est concerné

Tu n'as pas besoin d'être expert en sécurité pour faire un premier diagnostic. Voici quatre outils gratuits qui couvrent les vérifications de base.

Mozilla Observatory

URL : observatory.mozilla.org

Analyse les headers HTTP de ton site et attribue une note de A+ à F. En 30 secondes, tu sais si ton Content-Security-Policy, tes headers X-Frame-Options et Strict-Transport-Security sont en place.

Sur les sites PME qu'on audite, la note moyenne est D. Une note en dessous de B signifie que des protections de base manquent.

Security Headers

URL : securityheaders.com

Complémentaire à Mozilla Observatory. Vérifie spécifiquement les headers de sécurité HTTP et donne des recommandations claires pour chaque header manquant.

OWASP ZAP

URL : zaproxy.org (open source, gratuit)

C'est le scanner de vulnérabilités de référence. Il teste activement ton site contre les failles du OWASP Top 10. Plus technique que les deux précédents, mais c'est l'outil qu'on utilise en première passe d'audit.

SSL Labs

URL : ssllabs.com/ssltest

Analyse la configuration de ton certificat SSL/TLS. Note de A+ à F. Vérifie les protocoles supportés, la chaîne de certificats et les vulnérabilités connues (POODLE, Heartbleed).

Cas terrain : site e-commerce piraté et remédiation

En 2025, une PME lyonnaise spécialisée dans la vente de matériel professionnel nous contacte en urgence. Son site e-commerce PrestaShop ne fonctionne plus normalement : les clients sont redirigés vers un site de phishing au moment du paiement.

Ce qu'on a trouvé

En moins de deux heures d'audit, on a identifié le vecteur d'attaque : un module PrestaShop tiers (gestion des avis clients) qui n'avait pas été mis à jour depuis 18 mois. Une faille connue (CVE publié 14 mois plus tôt) permettait l'upload de fichiers PHP arbitraires.

L'attaquant avait déposé un fichier PHP dans le répertoire /modules/ qui modifiait le template de paiement pour injecter un iframe invisible redirigeant vers un site de phishing. Les données de carte bancaire étaient capturées avant même d'arriver chez le prestataire de paiement.

Ce qui aggravait la situation :

• Aucun monitoring en place — la redirection était active depuis 3 semaines
• Pas de backup exploitable récent (le dernier avait 4 mois)
• Le fichier .htaccess avait été modifié pour empêcher la détection par les scanners basiques
• Les logs serveur n'étaient pas activés

Ce qu'on a fait

Jour 1 : isolation du site (maintenance page), identification et suppression du code malveillant, restauration du template de paiement d'origine, mise à jour de tous les modules et du core PrestaShop.

Jour 2 : audit complet avec OWASP ZAP, correction des 7 autres failles identifiées (headers manquants, directory listing activé, fichiers sensibles accessibles, absence de CSRF sur les formulaires admin).

Jour 3-5 : mise en place d'un monitoring (alertes sur modification de fichiers critiques), configuration des logs serveur, backup automatisé quotidien, restriction d'accès au back-office par IP.

Le bilan

• Coût de la remédiation : environ 3 500 euros sur une semaine
• Coût estimé de l'incident : perte de CA sur 3 semaines (~12 000 euros), notification CNIL obligatoire (données bancaires concernées), perte de confiance clients difficilement chiffrable
• Coût d'une prévention : un audit annuel + maintenance mensuelle des mises à jour auraient coûté ~2 000 euros par an

La faille exploitée était connue et documentée depuis plus d'un an. Un simple composer audit ou une alerte Dependabot l'aurait signalée immédiatement.

Plan d'action sécurité en 5 étapes

Tu n'as pas besoin de tout faire d'un coup. Voici un plan progressif, de l'urgence à la consolidation.

1. Mettre à jour tout ce qui peut l'être (jour 1)

CMS, plugins, thèmes, dépendances npm/composer, version de PHP ou Node.js. C'est la première chose à faire parce que c'est la source numéro un d'exploitation : des failles connues sur des composants non mis à jour.

Commandes concrètes :

• WordPress : wp plugin update --all && wp core update
• Node.js : pnpm audit puis pnpm update
• PHP : composer audit puis composer update

2. Configurer les headers de sécurité (jour 2)

Ajoute ces headers dans la configuration de ton serveur (Apache, Nginx) ou de ton framework :

• Strict-Transport-Security (force HTTPS)
• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY
• Content-Security-Policy (restreint les sources de scripts)
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy (désactive les fonctionnalités non utilisées)

Teste ensuite avec securityheaders.com — vise la note A minimum.

3. Sécuriser l'authentification (semaine 1)

• Imposer des mots de passe de 12 caractères minimum
• Mettre en place le rate limiting sur la page de login (5 tentatives par minute max)
• Activer le 2FA pour les comptes admin
• Vérifier que les tokens de session sont régénérés après connexion

4. Mettre en place le monitoring (semaine 2)

• Activer les logs serveur (accès + erreurs)
• Configurer des alertes email sur les erreurs 401/403 anormales
• Installer un outil de détection de modification de fichiers (OSSEC, Wazuh, ou même un simple script cron)
• Mettre en place un backup automatisé quotidien avec rétention de 30 jours minimum

5. Planifier un audit complet (mois 1)

Un scan automatisé (OWASP ZAP) couvre les failles les plus évidentes. Mais certaines vulnérabilités (logique métier, contrôle d'accès, SSRF) nécessitent un regard humain.

Si ton site traite des données sensibles (paiement, données personnelles, accès client), un audit professionnel annuel n'est pas un luxe — c'est une obligation légale implicite au regard du RGPD (article 32 : "mesures techniques appropriées").

Pour les processus répétitifs de maintenance et de monitoring, on met en place des workflows automatisés qui alertent en temps réel sans intervention manuelle.

Checklist sécurité

FAQ

Conclusion

La sécurité web n'est pas un sujet réservé aux grandes entreprises ou aux secteurs réglementés. C'est un enjeu pour toute PME qui a un site en production.

• Les attaques sont automatisées — la taille de ton site n'est pas une protection
• Les failles les plus exploitées sont les plus basiques — mises à jour manquantes, headers absents, mots de passe faibles
• Les outils de diagnostic existent en gratuit — pas d'excuse pour ne pas faire un premier état des lieux
• La prévention coûte 10 à 50 fois moins cher que la remédiation — un audit annuel vs un incident qui paralyse ton activité
• La sécurité est un processus continu — pas un projet one-shot qu'on livre et qu'on oublie

Si tu as lu cet article jusqu'ici, tu as maintenant une vision claire de ce qui menace ton site et de ce que tu peux faire concrètement. Le premier pas, c'est de lancer les quatre outils gratuits mentionnés plus haut. Le deuxième, c'est de corriger ce qui sort en rouge.

Et si tu préfères qu'on s'en occupe — diagnostic, remédiation et mise en place d'un monitoring pérenne : Contactez-nous. Réponse sous 24h, sans engagement.