La première fois que j’ai ouvert le `.htaccess` de Barcelone, je ne savais même pas ce que j’y cherchais. J’étais là pour ajuster un site WordPress, mais j’ai fini par me cogner à un paramètre Apache si discret que je l’ai raté trois fois de suite. Quand j’ai enfin compris ce qu’il faisait, j’ai eu l’impression que quelqu’un venait de me remettre un bouclier invisible… et que je n’avais même pas besoin de le porter.
La clé cachée : ServerTokens et ses conséquences
Le paramètre s’appelait `ServerTokens`. Pour les non-initiés, c’est un outil qui contrôle ce que révèle le serveur web Apache à travers ses en-têtes. Par défaut, Apache affiche sa version, ses modules activés et même le système d’exploitation utilisé. C’est comme dire à un voleur : « J’ai une porte d’entrée en bois, une fenêtre au rez-de-chaussée et mon alarme est désactivée. »
En changeant `ServerTokens` de `Full` à `Prod`, j’ai simplement effacé ces informations. Rien de plus. Mais le résultat? Des robots automatisés qui testaient les vulnérabilités du serveur se sont soudainement arrêtés de taper. Pas une ligne de script modifiée, pas une alerte dans le code… juste une réponse HTTP qui devenait inutile pour les attaquants.
Comment le mettre en place
Si tu veux essayer, voici ce que j’ai fait :
Éditer le fichier de configuration Apache : Cherche `httpd.conf` ou `apache2.conf`.
Changer `ServerTokens Full` en `Prod` : Cela enlève la version, le système et les modules visibles.
Relancer Apache : `sudo systemctl restart apache2`.
C’est si basique que j’ai eu du mal à croire que personne n’en avait parlé. Pourtant, les sources comme le guide de l’SPHV le mentionnent comme une étape indispensable. Et un collègue l’a testé sur Point H : « D’un coup, les erreurs dans le journal d’activité sont devenues des noms vagues. Avant, c’était “Apache/2.4.54 OpenSSL/1.1.1n PHP/8.1.2”. Après? Juste “Apache” ».
Au-delà du paramètre : Les autres armes d’Apache
Le `ServerTokens` est un début, mais Apache offre d’autres outils puissants :
– ModSecurity : Un module de sécurité qui bloque les attaques par force brute, les injections SQL ou les tentatives de piratage automatisées. J’en ai activé un sur la machine, et les logs ont montré des tentatives de connexion échouées en 10 minutes.
– En-têtes de sécurité : Ajouter `X-Content-Type-Options: nosniff` ou `X-Frame-Options: DENY` empêche les navigateurs de traiter mal les fichiers, ce qui réduit les risques de XSS.
Ces ajustements coûtent peu en temps, mais les sources comme simeononsecurity insistent : ce sont les étapes indispensables pour un serveur en production.
Pourquoi ça marche
Le problème, c’est que la sécurité web ressemble souvent à un puzzle de milliers de pièces. On se focalise sur les fameux « bugs critiques », les vulnérabilités de code ou les attaques de haute technologie… et on oublie les bases.
Le `ServerTokens` est un exemple de cette base : il ne protège pas contre les failles techniques, mais il réduit la visibilité du serveur. En gros, il dit : « Je ne suis pas une cible facile ». Et c’est exactement ce que recherchent les pirates : des serveurs prévisibles, des configurations laissées en dur, des versions connues.
Le défi maintenant : Combien de temps dure le bouclier?
Un collègue a testé le `ServerTokens` pendant une semaine et n’a vu aucune tentative d’intrusion. Mais les robots s’adaptent. Demain, ils pourraient cibler les serveurs anonymes. Le message? C’est une protection parmi d’autres, pas une solution absolue.
Si tu veux en apprendre plus sur les outils WordPress pour renforcer sa sécurité, un article récent pourrait t’intéresser : Le plugin WordPress que j’ai redécouvert à Barcelone… et comment il a économisé 15h de travail par mois.
En attendant, si tu veux t’assurer que ton site n’est pas une cible facile… commence par ce paramètre. Et oui, ça marche, même si tu n’y connais rien à Linux.
— Élise Morane, étudiante en informatique et passionnée d’IA — Point Hub