Sécuriser un site web : quelles vulnérabilités surveiller ?

La sécurité d'un site n'est pas une case à cocher une fois pour toutes, mais une discipline continue. La bonne nouvelle, c'est que la majorité des incidents exploitent un petit nombre de failles bien connues et documentées. Comprendre ces vulnérabilités courantes et les pratiques qui les neutralisent permet de réduire fortement le risque, sans être un expert en cybersécurité.

Chiffrer les échanges avec HTTPS

La première brique est le HTTPS, qui chiffre les données échangées entre le navigateur et le serveur grâce à un certificat TLS. Sans lui, les informations transitent en clair et peuvent être interceptées sur le réseau. Aujourd'hui, des autorités comme Let's Encrypt délivrent des certificats gratuits et automatisables, ce qui rend le HTTPS accessible à tout site. Au-delà du chiffrement, il conditionne la confiance des visiteurs et des navigateurs, qui signalent les sites non sécurisés.

Les injections : quand une entrée devient une commande

Les failles d'injection figurent depuis des années parmi les risques majeurs recensés par l'OWASP (une organisation de référence sur la sécurité applicative). Le principe : une donnée envoyée par l'utilisateur est interprétée comme une instruction par le système.

• Injection SQL : un champ de formulaire manipulé permet d'altérer une requête vers la base de données, pour lire ou modifier des données non autorisées. La parade principale est l'usage de requêtes préparées (paramétrées), qui séparent strictement le code des données.
• Injection de commandes : une entrée non contrôlée est passée au système d'exploitation. Elle se prévient en évitant d'exécuter des commandes construites à partir d'entrées utilisateur.

La règle générale tient en une phrase : ne jamais faire confiance à une donnée venant de l'extérieur, et toujours la valider et l'échapper avant de l'utiliser.

Le XSS : du code injecté dans la page

Le Cross-Site Scripting (XSS) consiste à injecter du code JavaScript malveillant dans une page, souvent via un champ affiché ensuite à d'autres utilisateurs (commentaire, profil, message). Le script s'exécute alors dans le navigateur des victimes, permettant par exemple de voler des sessions. On s'en prémunit en échappant systématiquement les données affichées et en appliquant une politique de sécurité de contenu (Content Security Policy), qui restreint les sources de scripts autorisées.

Protéger l'authentification et les sessions

Les accès sont une cible privilégiée. Plusieurs pratiques réduisent nettement le risque :

• Stocker les mots de passe hachés avec un algorithme robuste et lent conçu pour cela (comme bcrypt ou Argon2), jamais en clair ni avec un simple chiffrement réversible.
• Imposer des mots de passe solides et proposer l'authentification à deux facteurs (2FA), qui bloque l'essentiel des attaques par mot de passe volé.
• Limiter les tentatives de connexion pour contrer les attaques par force brute.
• Sécuriser les cookies de session avec les attributs HttpOnly, Secure et SameSite, qui limitent leur vol et leur usage détourné.

Le CSRF et le principe du moindre privilège

La faille CSRF (Cross-Site Request Forgery) pousse un utilisateur authentifié à exécuter une action à son insu. On la contre avec des jetons anti-CSRF uniques par formulaire. Plus largement, le principe du moindre privilège consiste à n'accorder à chaque compte, service ou clé d'accès que les droits strictement nécessaires : un compte de base de données réservé à la lecture ne pourra pas être détourné pour tout effacer.

Tenir ses composants à jour

Une grande partie des sites reposent sur des briques tierces : CMS, extensions, bibliothèques. Les composants obsolètes contenant des failles connues sont l'une des causes d'intrusion les plus fréquentes, précisément parce que ces failles sont publiques. Maintenir à jour le socle logiciel, retirer les extensions inutilisées et surveiller les alertes de sécurité est l'une des mesures les plus rentables. C'est un travail de maintenance régulier, pas ponctuel.

Réduire la surface d'attaque

• Configurer correctement le serveur : désactiver l'affichage détaillé des erreurs en production, masquer les versions logicielles et fermer les services inutiles.
• Restreindre les accès d'administration et les protéger par HTTPS, mots de passe forts et 2FA.
• Gérer les téléversements de fichiers avec méfiance : contrôler le type et la taille, et stocker les fichiers hors du dossier exécutable.
• Sauvegarder régulièrement et tester la restauration : une sauvegarde saine reste le meilleur filet de sécurité face à un incident ou une compromission.

Sécuriser les accès à un site en production

Les failles applicatives décrites plus haut supposent un attaquant qui passe par la porte publique. Beaucoup d'incidents empruntent une voie plus directe : un accès légitime mal protégé. Le site de production n'est pas seulement une application, c'est aussi un serveur, un compte d'hébergement, un dépôt de code et une base de données — autant de portes distinctes.

Séparer la production du reste

• Un environnement de préproduction distinct, avec ses propres identifiants et ses propres données. Une copie de production laissée en ligne sur une adresse devinable, sans mot de passe et souvent sans les mises à jour, est un point d'entrée classique — et elle expose les mêmes données que le site réel.
• Interdire l'indexation et l'accès public de cet environnement par une authentification au niveau du serveur, plus fiable qu'une simple règle dans le fichier robots.
• Aucun secret dans le dépôt de code : identifiants de base, clés d'API et jetons vivent dans la configuration du serveur ou dans des variables d'environnement, pas dans les fichiers versionnés — un dépôt privé peut devenir public par erreur, l'historique, lui, garde tout.

Protéger les accès techniques

• Connexion serveur par clé plutôt que par mot de passe, avec l'authentification par mot de passe désactivée côté SSH ; les tentatives automatisées, elles, ne s'arrêtent jamais.
• Transferts chiffrés uniquement : SFTP ou SSH, jamais le FTP en clair, qui expose les identifiants sur le réseau.
• Un compte par personne et par service, révocable individuellement. Un identifiant partagé entre plusieurs intervenants ne se retire pas au départ de l'un d'eux, et ne dit rien de qui a fait quoi.
• Restreindre l'administration : filtrage par adresse IP quand c'est possible, authentification à deux facteurs sinon, et limitation des tentatives dans tous les cas.

Réduire ce que la production révèle

• Aucun affichage d'erreur détaillé côté public : un message de débogage livre des chemins de fichiers, des versions et parfois des fragments de requête.
• Pas d'outil de développement laissé en ligne — interface d'administration de base de données, sondes de profilage, fichiers d'installation, archives de sauvegarde déposées dans le dossier public.
• Des droits de base de données limités à ce dont l'application a besoin : le compte utilisé par le site n'a aucune raison de pouvoir supprimer des tables.
• Rotation des identifiants après chaque départ d'un intervenant ou chaque suspicion de fuite, y compris les clés d'API des services tiers.

La sécurité, une posture continue

Face à des menaces qui visent aussi bien les applications web que les systèmes qui les hébergent, aucune mesure isolée ne suffit : c'est leur combinaison qui protège. Le modèle utile est celui de la défense en profondeur : superposer plusieurs couches (chiffrement, validation des entrées, contrôle des accès, mises à jour, sauvegardes) pour qu'une faille unique ne suffise pas à compromettre l'ensemble. La sécurité n'est jamais garantie à 100 %, mais une hygiène technique rigoureuse écarte l'immense majorité des attaques opportunistes, qui visent d'abord les cibles les moins protégées.