10 failles de sécurité web courantes à sécuriser absolument

La sécurité d’un site web n’est pas un luxe, c’est une nécessité absolue. Chaque jour, des milliers de sites — qu’ils soient personnels, vitrines ou e-commerces — sont victimes d’attaques informatiques. Parfois, ces attaques passent inaperçues pendant des semaines. D’autres fois, elles provoquent des pertes de données, des vols d’informations sensibles ou encore des blocages complets du site.

Si vous possédez un site internet, même tout petit, vous êtes une cible potentielle. Les pirates n’attaquent pas uniquement les grandes entreprises : ils automatisent leurs attaques et cherchent les failles les plus simples à exploiter. Une seule négligence dans votre code ou dans la configuration de votre serveur peut suffire à leur ouvrir la porte.

Dans ce guide, nous allons voir ensemble les 10 failles de sécurité les plus fréquentes sur un site web, comment elles fonctionnent et surtout comment les éviter. Ce guide a été conçu pour être accessible à tous, même si vous débutez en développement web ou en administration de site. Vous comprendrez clairement ce qu’il se passe, pourquoi c’est dangereux et ce que vous pouvez faire pour vous protéger.

1. L’injection SQL : la faille la plus connue et la plus dangereuse

L’injection SQL (ou SQL Injection) est probablement la faille la plus célèbre du web. Elle consiste à exploiter une faiblesse dans une requête SQL pour exécuter du code malveillant directement dans la base de données.

Prenons un exemple simple. Imaginons que vous ayez une page de connexion avec un formulaire où l’utilisateur saisit son pseudo et son mot de passe. En PHP, vous pourriez être tenté d’écrire une requête comme celle-ci :

$requete = "SELECT * FROM users WHERE pseudo = '" . $_POST['pseudo'] . "' AND password = '" . $_POST['password'] . "'";

Si l’utilisateur malveillant entre le texte suivant dans le champ pseudo :

' OR '1'='1

La requête devient :

SELECT * FROM users WHERE pseudo = '' OR '1'='1' AND password = '';

Résultat : la condition '1'='1' est toujours vraie, et l’attaquant peut se connecter sans connaître de mot de passe !

Pourquoi c’est dangereux ?
Parce que l’attaquant peut aller beaucoup plus loin : supprimer des données, lire des mots de passe, voire prendre le contrôle total de votre base.

Comment se protéger ?
Il suffit d’utiliser des requêtes préparées ou paramétrées. En PHP, par exemple, avec PDO :

$stmt = $pdo->prepare("SELECT * FROM users WHERE pseudo = :pseudo AND password = :password");
$stmt->execute(['pseudo' => $_POST['pseudo'], 'password' => $_POST['password']]);

Ici, le contenu saisi par l’utilisateur n’est plus directement injecté dans la requête SQL : il est traité comme une simple donnée, et non comme du code exécutable.

Pour vous protéger, consultez notre Guide complet sur les Injections SQL.

2. Le Cross-Site Scripting (XSS) : l’art d’injecter du code dans vos pages

Le Cross-Site Scripting (XSS) est une faille très courante qui permet à un pirate d’injecter du code JavaScript malveillant dans une page web. Ce code peut ensuite s’exécuter dans le navigateur de vos visiteurs.

Prenons un exemple : votre site affiche les commentaires laissés par les internautes sans vérifier ce qu’ils contiennent. Si un visiteur malveillant entre le message suivant :

<script>alert('Vous avez été piraté !');</script>

Alors, chaque fois qu’un autre utilisateur affichera ce commentaire, le script s’exécutera dans son navigateur.

Cela peut sembler anodin dans cet exemple, mais le pirate pourrait, à la place, voler les cookies de session, rediriger les visiteurs vers un site piégé, ou encore injecter un faux formulaire pour voler des mots de passe.

Pourquoi c’est dangereux ?
Parce que le code s’exécute côté client (dans le navigateur). Il est donc très difficile pour vos visiteurs de se rendre compte qu’ils sont victimes d’un script malveillant venant de votre propre site.

Comment se protéger ?
Il faut toujours filtrer et échapper les données avant de les afficher. En PHP, la fonction htmlspecialchars() est essentielle :

echo htmlspecialchars($commentaire);

Elle empêche le navigateur d’interpréter les balises HTML comme du code, ce qui neutralise les tentatives de script.

De plus, il est recommandé d’utiliser des en-têtes HTTP comme Content-Security-Policy pour limiter les scripts autorisés sur votre site.

Pour aller plus loin, consultez notre Guide pour détecter une faille XSS.

3. Les failles d’authentification et de gestion de session

La sécurité ne s’arrête pas au code : elle dépend aussi de la manière dont les utilisateurs s’identifient et conservent leur connexion. Les failles d’authentification sont parmi les plus exploitées, car elles permettent à un pirate de se faire passer pour un autre utilisateur.

Un cas typique est celui du mot de passe faible. Beaucoup d’utilisateurs choisissent des mots de passe simples comme « azerty123 » ou « admin ». Ces combinaisons peuvent être devinées ou testées très rapidement grâce à des attaques dites par force brute (où un programme teste des milliers de combinaisons par seconde).

Découvrez Comment craquer un mot de passe.

Un autre problème fréquent concerne la gestion des sessions. Lorsqu’un utilisateur se connecte, une session est créée pour le reconnaître sur les pages suivantes. Si cette session est mal sécurisée, un pirate peut la voler. Cela peut se produire, par exemple, si le cookie de session n’est pas chiffré, ou si le site ne force pas le protocole HTTPS.

Apprenez à ajouter un Certificat HTTPS et SSL à votre site web.

Pourquoi c’est dangereux ?
Parce qu’une fois la session volée, l’attaquant peut agir exactement comme si c’était l’utilisateur : modifier son profil, accéder à des données personnelles ou administrer le site.

Comment se protéger ?

• Forcer les connexions en HTTPS, ce qui chiffre les échanges entre le navigateur et le serveur.
• Générer des identifiants de session aléatoires et difficiles à deviner.
• Utiliser des cookies sécurisés, avec les attributs HttpOnly (pour empêcher l’accès en JavaScript) et Secure (pour n’être envoyés que sur HTTPS).
• Imposer des mots de passe forts : au moins 12 caractères, combinant majuscules, minuscules, chiffres et symboles.

Pour les sites qui gèrent des comptes, il est aussi conseillé de mettre en place une double authentification (2FA). Même si un mot de passe fuitait, l’attaquant ne pourrait pas se connecter sans le code secondaire (souvent envoyé par SMS ou via une application).

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

Apprenez à Sécuriser une session PHP

4. Mauvaise gestion des téléchargements de fichiers : la porte ouverte aux exécutables

Permettre aux utilisateurs d’envoyer des fichiers (images, CV, documents) est très courant. Pourtant, c’est une des fonctions les plus risquées si elle n’est pas correctement protégée. Un fichier censé être une image peut en réalité contenir du code exécutable ou une extension déguisée. Un pirate peut ainsi déposer un script sur le serveur, puis l’exécuter depuis le web pour prendre le contrôle.

Un exemple concret : un formulaire accepte uniquement « .jpg » mais ne vérifie pas le contenu du fichier. L’attaquant renomme un fichier PHP en « photo.jpg.php » ou modifie les en-têtes pour tromper la vérification. Si le serveur exécute ensuite ce fichier, l’attaquant peut exécuter n’importe quelle commande.

Comment se protéger ?
D’abord, valider le type MIME du fichier côté serveur et non seulement côté client. Ensuite, stocker les fichiers téléchargés en dehors du répertoire web public ou dans un dossier dont l’exécution de scripts est désactivée. Renommer systématiquement les fichiers avec un identifiant aléatoire et refuser les extensions potentiellement dangereuses. Enfin, si une image doit être affichée, la ré-encoder côté serveur (par exemple ouvrir l’image et la sauver à nouveau) pour éliminer tout contenu caché. Limiter la taille des fichiers et scanner les fichiers avec un antivirus côté serveur ajoute une couche de sécurité.

Pour allez plus loin : Tout savoir sur l’Upload sécurisé de fichiers

5. Mauvaises configurations serveur : la vulnérabilité qui coûte cher

Un serveur mal configuré peut exposer des informations sensibles sans qu’aucun code ne soit vulnérable. Des répertoires listés, des fichiers de sauvegarde accessibles, des versions logicielles affichées, ou des permissions trop larges, tout cela facilite le travail d’un attaquant.

Illustration : si le serveur affiche par erreur l’index d’un dossier, un pirate peut lister l’arborescence et trouver des fichiers de configuration (.env, config.php) contenant mots de passe et clés. Pareillement, laisser activer des services inutiles ou des ports ouverts multiplie les points d’entrée.

Mesures concrètes : masquer les versions des serveurs, désactiver la navigation dans les répertoires, limiter strictement les permissions des fichiers (par exemple 640 ou 600 pour les fichiers sensibles), fermer les ports non utilisés, et utiliser un pare-feu applicatif (WAF) pour filtrer les requêtes malveillantes. Documenter et automatiser la configuration (Infrastructure as Code) réduit les erreurs humaines.

6. Cross-Site Request Forgery (CSRF) : agir sans se rendre compte

Le CSRF permet à un attaquant de faire exécuter une action sur votre site par un utilisateur authentifié, sans que celui-ci en ait conscience. Par exemple, si un utilisateur est connecté à son espace bancaire et visite un site malveillant, ce dernier peut envoyer une requête au site bancaire pour transférer de l’argent — et le navigateur inclura automatiquement les cookies de session, rendant la requête valide.

Exemple simple : un formulaire de modification d’email qui ne vérifie pas l’origine de la requête peut être déclenché par un formulaire caché sur une autre page.

Prévention : chaque formulaire proposant une action sensible doit inclure un jeton CSRF unique et vérifiable côté serveur. Ce jeton est généré pour la session utilisateur et doit être présent et valide lors de la réception. Pour les requêtes AJAX, le jeton peut être envoyé dans un en-tête personnalisé. En outre, vérifier l’en-tête Origin ou Referer peut aider, mais ce n’est pas suffisant seul.

7. Failles dans les bibliothèques ou plugins tiers : la dette technique qui revient

Utiliser des bibliothèques, frameworks ou plugins accélère le développement. Mais chaque composant ajouté est une surface d’attaque potentielle. Les vulnérabilités connues dans des bibliothèques courantes (gestionnaires d’images, extensions CMS, composants JS) sont souvent automatisées par des scanners d’attaque.

Cas courant : un plugin de CMS n’est plus maintenu et contient une faille qui permet d’obtenir un accès administrateur. Sur des centaines de sites utilisant ce plugin, les attaques automatisées ciblent cette faiblesse.

Que faire ?
Mettre à jour régulièrement toutes les dépendances, surveiller les annonces de sécurité des projets utilisés, et supprimer les plugins inutiles. Quand possible, privilégier des bibliothèques maintenues et populaires. Intégrer un outil d’analyse des vulnérabilités dépendances (SCA) dans le processus de déploiement aide à détecter automatiquement les versions vulnérables.

8. Accès non restreint aux fichiers sensibles : exposer sans le vouloir

Des fichiers sensibles peuvent être présents sur le serveur : sauvegardes, fichiers de configuration, clés API, exports CSV. Si ces fichiers sont accessibles publiquement, ils deviennent une mine d’or pour un attaquant.

Exemple : un fichier backup.sql laissé dans un dossier public contient la structure et les données de la base. Un robot peut le télécharger et extraire des identifiants.

Mesures : placer les fichiers sensibles en dehors de la racine web, ou appliquer des règles d’accès strictes via le serveur web (rewrite rules, protection par mot de passe pour des zones d’administration). Chiffrer les sauvegardes et limiter l’accès via des comptes dédiés. Enfin, automatiser la purge des anciens fichiers pour réduire l’exposition.

9. Stockage des mots de passe en clair : erreur capitale

Stocker les mots de passe des utilisateurs en clair dans la base de données est une pratique dangereuse. En cas de fuite, l’attaque expose immédiatement tous les mots de passe. Les utilisateurs réutilisent souvent leurs identifiants, ce qui étend l’impact.

La bonne pratique consiste à ne jamais stocker un mot de passe en clair, mais à stocker son empreinte (hash) en utilisant un algorithme adapté pour les mots de passe, comme Argon2 ou bcrypt, avec un sel (salt) unique par utilisateur. Ces algorithmes rendent la récupération du mot de passe extrêmement coûteuse en temps et en ressources.

Exemple de mise en oeuvre en PHP : utiliser password_hash() et password_verify() qui encapsulent bcrypt/argon2 selon la configuration. En parallèle, forcer des politiques de mots de passe robustes et proposer la réinitialisation par email plutôt que l’envoi du mot de passe.

Découvrez notre Tutoriel complet sur la Cryptographie.

10. Manque de mises à jour et de surveillance : l’usure du temps

Un site non mis à jour ou non surveillé finit par accumuler des vulnérabilités. Les correctifs de sécurité sont publiés régulièrement ; ne pas les appliquer, c’est laisser la porte ouverte. En parallèle, l’absence de logs et d’alertes empêche de détecter une intrusion à temps.

Mesures pratiques : mettre en place une politique de mises à jour régulières pour le système d’exploitation, le serveur web, le langage et les dépendances. Automatiser les déploiements quand c’est possible. Installer des outils de surveillance qui alertent en cas d’activité anormale (logs d’accès, erreurs 500 massives, tentatives de connexions répétées). Conserver des sauvegardes hors-site et tester les procédures de restauration pour s’assurer qu’elles fonctionnent.

Pour allez plus loin, découvrez comment Analyser et interpréter les logs d’un serveur web.

Transformer la sécurité en habitude

Protéger un site web ne relève pas d’un rituel ponctuel mais d’un état d’esprit. Les failles présentées ici — injecter du SQL, XSS, mauvaises configurations, gestion de fichiers, CSRF, composants tiers, accès à des fichiers sensibles, mots de passe en clair et absence de mises à jour — sont responsables de la majorité des compromissions. Elles apparaissent souvent à cause d’un manque de vigilance, de procédures ou d’automatisation.

La prochaine étape consiste à rendre la sécurité pratique et répétable. Mettre en place un processus simple et documenté : vérifier les dépendances avant chaque déploiement, automatiser les sauvegardes, appliquer les mises à jour critiques, contrôler l’accès aux fichiers et ajouter des protections de base comme HTTPS, CSP, jetons CSRF et hachage des mots de passe. Surveillez les logs et appliquez des scans réguliers de vulnérabilités. Et surtout, considérez la sécurité comme un investissement : quelques heures passées à configurer correctement un serveur ou à corriger un plugin valent mieux que des semaines de reprise après incident.

Pour aller plus loin, explorer les ressources spécialisées (les recommandations OWASP, guides de configuration du serveur web, outils d’analyse automatique) permet de structurer une démarche pérenne. En appliquant progressivement ces bonnes pratiques, il est possible de réduire très fortement le risque et d’offrir aux visiteurs un site plus fiable et serein.

Alban

Fondateur de l’agence Créa-troyes.
Intervenant en Freelance.
Contactez-moi

crea-troyes.fr