La question qui revient le plus souvent quand on me parle de sécurité web, ce n'est pas « comment je fais un pare-feu ? ». C'est : « comment je sais que mon site n'est pas déjà compromis ? » Et là, franchement, la plupart des gens découvrent la vérité par une mauvaise nouvelle : une page de phishing hébergée dans un sous-dossier oublié, un formulaire de contact qui envoie du spam depuis six semaines, ou un avertissement rouge dans la console de recherche qui casse le référencement du jour au lendemain.
J'ai vécu ce dernier cas sur un projet client il y a quelques années. Le site était propre en apparence. Le problème venait d'un vieux plugin de galerie photo, abandonné depuis dix-huit mois, qui avait laissé passer une injection. Trois semaines avant que je m'en aperçoive. Depuis, ma façon d'aborder la sécurisation d'un site a changé du tout au tout : moins de gadgets, plus de vérifications basiques et régulières.
Points clés à retenir
- HTTPS et les en-têtes de sécurité HTTP ne sont pas des options cosmétiques : ils bloquent des catégories entières d'attaques côté navigateur.
- La majorité des compromissions réelles viennent de dépendances obsolètes, pas de failles exotiques.
- Le principe du moindre privilège s'applique aux utilisateurs, aux comptes de service et même aux clés d'API.
- Une sauvegarde jamais testée n'est pas une sauvegarde : c'est une croyance.
- Savoir réagir après une intrusion compte autant que de l'empêcher.
Sécuriser un site web : HTTPS ne suffit pas, voici les en-têtes qu'on oublie
Tout le monde vous répète qu'il faut un certificat TLS. C'est vrai. C'est aussi le niveau zéro, celui que votre hébergeur installe en deux clics. Le cadenas dans la barre d'adresse ne dit rien de la robustesse de votre application.
Ce qui compte davantage, et dont on parle rarement, ce sont les en-têtes de réponse HTTP. Ils indiquent au navigateur comment se comporter face à votre contenu, et ils ferment des portes que le chiffrement laisse grandes ouvertes.
CSP, HSTS, X-Frame-Options : le trio de base
Le Content Security Policy (CSP) reste le plus mal compris. Concrètement, il liste les sources depuis lesquelles le navigateur a le droit de charger scripts, styles et images. Sans lui, une faille d'injection de script devient immédiatement exploitable. Avec une CSP correcte, l'attaquant n'a nulle part où envoyer son code.
Le HSTS force le navigateur à ne plus jamais contacter votre domaine en HTTP clair. Une fois activé, plus de rétrogradation possible. Je l'ai déployé sur un site e-commerce, et le nombre de redirections inutiles a chuté de manière visible dans les journaux serveur.
X-Frame-Options empêche votre site d'être intégré dans une iframe invisible pour du clickjacking. Le principe est simple : un clic de l'utilisateur ne doit jamais pouvoir être détourné vers une action qu'il n'a pas voulue.
Avouons-le : aucun de ces en-têtes ne vous protégera si votre code applicatif est troué. Ils réduisent la surface d'attaque, ils ne la suppriment pas. C'est une nuance que beaucoup de checklists effacent.
Same Origin Policy et CORS : ce que le navigateur fait pour vous
Le navigateur applique nativement la Same Origin Policy. En clair, un script chargé depuis un autre domaine ne peut pas lire arbitrairement vos données. C'est une protection par défaut, et de nombreuses configurations CORS mal écrites la cassent en autorisant n'importe quelle origine.
Si vous voyez un en-tête du type Access-Control-Allow-Origin: * en production sur une API sensible, il y a un problème. Trois ans après ma première mise en production, je fais encore cette vérification avant chaque déploiement.
Mises à jour et mots de passe : là où la vraie faille se cache
Vous avez peut-être remarqué que presque tous les incidents de sécurité que je mentionne remontent à une dépendance oubliée. Ce n'est pas un hasard. Les failles spectaculaires font la une, mais la majorité des intrusions réelles passent par des composants que personne ne met à jour.
Le problème n°1 : les dépendances obsolètes
Sur un site que j'ai repris, le gestionnaire de dépendances affichait 42 paquets avec des versions vulnérables connues. Personne ne s'en était inquiété. Certains n'avaient pas été touchés depuis plus de deux ans. Le site fonctionnait, donc tout allait bien, pensait-on.
Ma méthode, désormais systématique :
- Lister toutes les dépendances, y compris celles indirectes.
- Identifier celles qui ne sont plus maintenues depuis plus d'un an et les remplacer ou les isoler.
- Automatiser un scan de vulnérabilités à chaque build.
- Ne jamais fusionner une mise à jour de sécurité sans relecture — mais ne jamais la repousser non plus.
Cette routine m'a coûté deux heures par semaine au début. Elle m'a évité au moins deux incidents que je n'ai jamais eus à corriger parce qu'ils n'ont pas eu lieu.
Le principe du moindre privilège en pratique
Qu'est-ce que le principe du moindre privilège ? C'est la règle qui consiste à n'accorder à chaque compte, service ou processus que les droits stricts dont il a besoin pour fonctionner, et rien de plus. Un compte de sauvegarde doit pouvoir écrire dans le stockage et lire la base, pas administrer le serveur.
Dans la pratique, c'est souvent mal appliqué. J'ai vu des applications se connecter à la base de données avec les droits d'administrateur parce que « c'est plus simple ». Puis une injection SQL transforme cette simplicité en compromission totale.
| Contexte | Erreur courante | Application du moindre privilège |
|---|---|---|
| Compte de base de données | Droits admin pour tout | Droits en lecture seule sur les tables non modifiées |
| Comptes utilisateurs | Un seul rôle « admin » global | Rôles hiérarchisés selon les besoins réels |
| Clés d'API | Une clé unique réutilisée partout | Une clé par usage, avec périmètre et expiration |
| Accès serveur | SSH root permanent | Accès temporaire et journalisé |
Ce tableau semble évident. En audit, on rencontre pourtant ces quatre situations en moyenne sur chaque projet non préparé.
Comment vérifier si un site est fiable ou sécurisé ?
Vérifier la sécurité d'un site, le vôtre ou celui d'un tiers, se fait aujourd'hui avec des outils accessibles à tous, sans compétence technique approfondie.
Comment tester la sécurité d'un site web en ligne ?
Plusieurs services gratuits permettent d'obtenir un diagnostic. Ils testent la présence des en-têtes de sécurité, la validité du certificat, la version de TLS, et parfois des failles de configuration évidentes. Des outils comme Security Headers, SSL Labs ou Observatory de Mozilla donnent une note synthétique en quelques secondes.
Ces outils ne remplacent pas un audit, mais ils révèlent 80 % des problèmes de configuration visibles depuis l'extérieur. Je les lance systématiquement avant toute mise en production.
Comment savoir si un site est fiable ?
Pour évaluer un site tiers — un fournisseur, un concurrent, un prestataire — je regarde trois choses concrètes :
- Le certificat TLS est-il valide et à jour ?
- Les en-têtes de sécurité sont-ils présents, ou absents ?
- Le site expose-t-il publiquement des technologies obsolètes (versions de serveur, frameworks anciens) ?
Une absence totale d'en-têtes de sécurité sur un site marchand, par exemple, est un signal. Pas une preuve de compromission, mais un indicateur qu'on ne se préoccupe pas de ce sujet.
Comment sécuriser un site non sécurisé ?
Un site « non sécurisé » au sens du navigateur, c'est-à-dire sans HTTPS, se corrige plus vite qu'on ne le croit. Le certificat est gratuit chez la plupart des hébergeurs et des autorités de certification modernes. La bascule HTTP vers HTTPS demande une redirection permanente, une mise à jour des liens internes, et la vérification qu'aucune ressource mixte ne subsiste.
Le piège classique : un contenu en HTTP chargé depuis une page HTTPS. Le cadenas disparaît, et l'utilisateur reçoit un avertissement. J'ai passé une après-midi entière à traquer une image qui venait d'un ancien CDN sur un site pourtant migré depuis des mois.
Après le HTTPS, ce qui reste à faire
Migrer en HTTPS n'est que le début. Ce qui compte ensuite :
- Forcer HSTS pour éviter toute rétrogradation.
- Vérifier les redirections dans les deux sens.
- Mettre à jour les liens externes et les signatures d'e-mail.
- Corriger les ressources mixtes signalées dans la console du navigateur.
Sauvegardes et réaction après incident : la partie qu'on oublie
Une sauvegarde régulière dont on n'a jamais testé la restauration ne vaut rien. J'ai appris ça en voyant un site perdre trois jours de données parce que les fichiers étaient bien sauvegardés, mais que la base ne l'était qu'une fois par semaine.
Ce qu'il faut vérifier :
- La fréquence correspond-elle à la valeur des données ?
- La restauration a-t-elle été testée au moins une fois ?
- Les sauvegardes sont-elles isolées du serveur de production ?
- Qui peut y accéder ?
En cas d'incident réel, l'ordre des priorités est contre-intuitif. On isole d'abord. On analyse ensuite. On restaure en dernier. Beaucoup de gens font l'inverse et écrasent les preuves dont ils avaient besoin pour comprendre ce qui s'est passé.
Et une dernière chose, un peu à contre-courant : la meilleure façon de sécuriser un site, ce n'est pas d'empiler des outils, c'est de réduire la surface. Moins de plugins, moins de comptes, moins d'expositions. La sécurité, à la fin, c'est souvent une histoire de soustraction plus que d'addition.
