Renforcer la sécurité du site : permissions, en-têtes et extensions de sécurité

Module 7: Sécurité · Temps de lecture : 10 minutes

Objectif pédagogique : à l'issue de cette leçon, vous serez capable de renforcer la sécurité d'un site WordPress à l'aide des permissions, des réglages et des en-têtes de sécurité, et d'évaluer les extensions de sécurité à leur juste valeur.

Notions clés : renforcement (hardening), permissions de fichiers (644, 755), DISALLOW_FILE_EDIT, pas de PHP dans uploads, liste de répertoire, masquage de version, X-Powered-By, en-têtes de sécurité, fichiers de sauvegarde et .git dans le répertoire web, WAF sur le serveur, WAF dans une extension, scanner de malware

Ce qu'est le renforcement

Renforcer la sécurité signifie : configurer le site de telle sorte qu'une erreur ou une faille cause le moins de dégâts possible. Cela ne remplace pas les mises à jour ni les mots de passe robustes (leçon 7.2 et 7.3), mais cela réduit les conséquences. Pensez à une maison : les mises à jour sont les serrures, le renforcement consiste à faire en sorte qu'un cambrioleur déjà entré ne puisse pas accéder au coffre-fort.

Permissions de fichiers

Chaque fichier et chaque répertoire sur le serveur possède des permissions : qui peut lire, écrire et exécuter. Elles s'écrivent sous forme de trois chiffres, pour le propriétaire, le groupe et le reste du monde. La recommandation de la documentation de WordPress :

La valeur qui fonctionne pour wp-config.php dépend de la façon dont votre hébergeur exécute PHP : sur la plupart des hébergements mutualisés, PHP s'exécute en tant que votre propre utilisateur, et 600 suffit alors. Essayez et vérifiez que le site fonctionne toujours.

Jamais 777. Cela signifie que tout le monde sur le serveur peut écrire. Un guide qui dit « mettez le répertoire en 777 si le téléversement ne fonctionne pas » résout le problème de la mauvaise manière. Avec un bon hébergement, ce n'est d'ailleurs jamais nécessaire.

Réglages dans wp-config.php

Quelques lignes qui font une grande différence (au-dessus de « Arrêtez l'édition ») :

// Aucune modification de fichiers depuis l'administration (Apparence > Éditeur de thèmes et Extensions > Éditeur d'extensions).
define( 'DISALLOW_FILE_EDIT', true );

// Les messages d'erreur ne doivent jamais s'afficher à l'écran des visiteurs (leçon 5.4).
define( 'WP_DEBUG', false );

Avec DISALLOW_FILE_EDIT, l'éditeur permettant de modifier les fichiers PHP des thèmes et des extensions depuis l'administration disparaît. Un cambrioleur qui prend le contrôle d'un compte administrateur ne peut alors pas insérer du code malveillant dans votre thème en deux clics. Vous pouvez toujours installer des extensions ; si vous souhaitez l'interdire aussi (par exemple pour un site que vous gérez pour un client), il existe DISALLOW_FILE_MODS, mais alors les mises à jour depuis l'administration ne fonctionneront plus non plus.

Pas de PHP dans uploads, pas de liste de répertoire

Dans wp-content/uploads, on trouve des images et des documents, jamais de fichiers PHP. Les cambrioleurs qui parviennent à téléverser un fichier via une faille essaient justement d'y déposer un fichier PHP puis de l'exécuter. Bloquez cela avec un .htaccess dans le répertoire uploads (sous LiteSpeed et Apache) :

<Files *.php>
Require all denied
</Files>

Désactivez aussi l'affichage des répertoires. Sans index.php ni index.html dans un répertoire, certains serveurs web affichent une liste de tous les fichiers (« Index of /wp-content/uploads/2026/11 »). C'est une vitrine pour qui recherche des sauvegardes ou des documents sensibles. Dans le .htaccess de votre répertoire web :

Options -Indexes

De nombreux hébergeurs désactivent déjà cela par défaut. L'exercice de cette leçon le vérifie.

Pas de restes dans le répertoire web

Tout ce qui se trouve dans le répertoire web est accessible via le web, sauf ce que le serveur exécute comme PHP ou bloque. Sont dangereux :

• les copies de wp-config.php (wp-config.php.bak, wp-config.old, wp-config.php~ laissé par un éditeur de texte) : elles contiennent votre mot de passe de base de données et sont envoyées comme texte brut (leçon 1.3) ;
• les sauvegardes telles que backup.zip, site.tar.gz ou database.sql dans le répertoire web ;
• un répertoire .git laissé par un développeur, permettant à quelqu'un de télécharger tout votre code (et parfois des mots de passe) ;
• debug.log dans wp-content (leçon 5.4) ;
• d'anciens fichiers d'installation ou de test comme info.php contenant phpinfo().

Conservez vos sauvegardes en dehors du répertoire web ou en dehors du serveur, et supprimez les restes.

Masquer la version : un gain minime

WordPress insère par défaut dans le HTML :

<meta name="generator" content="WordPress 7.1.4" />

et la même chose dans le flux RSS. PHP aussi se signale parfois dans un en-tête : X-Powered-By: PHP/8.3.14. Masquer cela est raisonnable, mais n'en attendez pas trop : les programmes des cambrioleurs testent simplement une faille, quelle que soit la version affichée, et les versions se déduisent souvent aussi de ?ver= après les scripts. Masquer, c'est faire le ménage, pas sécuriser. Un site qui masque sa version mais ne se met pas à jour reste tout aussi vulnérable.

Voici comment procéder, dans une petite extension personnelle ou dans functions.php de votre thème enfant :

remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );

Et pour l'en-tête PHP, avec expose_php = Off dans les réglages PHP de votre hébergeur (sous DirectAdmin dans Select PHP version, Options), ou avec Header unset X-Powered-By dans .htaccess.

En-têtes de sécurité

Quelques en-têtes permettent d'indiquer au navigateur comment se comporter avec votre site. Les plus importants :

Dans .htaccess (sous LiteSpeed et Apache) :

<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Testez ensuite que tout fonctionne : contenu intégré, boutons de paiement, widget de chat. Des outils externes comme securityheaders.com et internet.nl montrent ce que votre site envoie.

Les extensions de sécurité, un regard honnête

Il existe de nombreuses extensions de sécurité (par exemple Wordfence, Solid Security, All-In-One Security, Sucuri). Elles regroupent souvent : un pare-feu, un scanner de malware, une protection de connexion, l'authentification à deux facteurs, des alertes et une liste de renforcement. Utiles, mais avec des limites :

• Un pare-feu dans une extension (WAF) ne démarre qu'une fois PHP en cours d'exécution. Une requête malveillante doit d'abord traverser le serveur web et PHP avant que l'extension ne la voie. Une faille dans un fichier PHP appelé directement, ou une attaque qui surcharge PHP lui-même, n'est pas toujours arrêtée. Un pare-feu sur le serveur (par exemple Modsecurity, Imunify360 ou un pare-feu de votre hébergeur) se trouve plus tôt dans la chaîne et arrête davantage de menaces, sans que votre extension ne fasse le travail de calcul. Demandez à votre hébergeur ce qui tourne sur le serveur.
• Un scanner détecte après coup. Un scanner de malware vous signale qu'il y a un problème. C'est précieux, mais cela ne prévient rien. Et un scanner situé sur le même serveur qu'un site piraté peut lui-même avoir été modifié par le cambrioleur.
• Elles ne remplacent pas les mises à jour. Une extension comportant une faille connue reste vulnérable, même avec une extension de sécurité à ses côtés. Certains services de sécurité proposent des « correctifs virtuels » qui bloquent des attaques connues en attendant votre mise à jour ; pratique comme solution temporaire, pas comme remplacement.
• Elles sont elles-mêmes une extension. Plus de code, plus à mettre à jour, et parfois une faille en elle-même. Et deux extensions de sécurité en même temps entrent souvent en conflit.
• Elles consomment des ressources, surtout les scanners qui s'exécutent sur votre propre serveur.

Un choix raisonnable : regardez d'abord ce que votre hébergeur fait déjà (pare-feu, analyse antimalware, blocage des tentatives de connexion). Complétez ce qui manque, généralement l'authentification à deux facteurs et la limitation des tentatives de connexion. Une extension de sécurité complète est surtout utile avec un hébergement qui fait lui-même peu de choses.

Résumé

• Le renforcement limite les dégâts d'une erreur ou d'une faille ; il ne remplace pas les mises à jour ni les mots de passe.
• Répertoires en 755, fichiers en 644, wp-config.php plus strict ; jamais 777.
• Activez DISALLOW_FILE_EDIT, bloquez PHP dans uploads, désactivez les listes de répertoire et supprimez les sauvegardes, .git et debug.log du répertoire web.
• Masquer la version, c'est faire le ménage, pas sécuriser ; les en-têtes de sécurité aident le navigateur à protéger vos visiteurs.
• Un pare-feu sur le serveur arrête davantage de menaces qu'une extension ; les extensions de sécurité sont un complément, pas un remplacement.

Quiz

Exercice

Exercice A7.4 : Que montre votre site à tout le monde ? Indiquez l'adresse de votre site. Le programme lit la page d'accueil et le flux RSS (/feed/) et vérifie : qu'aucune version de WordPress ne figure dans la balise generator du HTML et du flux, que l'en-tête X-Powered-By n'affiche pas de version de PHP, et que votre site envoie X-Content-Type-Options: nosniff, une protection contre les frames (X-Frame-Options ou frame-ancestors) et une Referrer-Policy. L'absence de HSTS (leçon 3.1) et de Permissions-Policy est tolérée (orange).

Exercice A7.4b : Pas de restes dans le répertoire web. Prouvez qu'il s'agit bien de votre site (enregistrement TXT ou fichier contenant le code de l'exercice). Le programme interroge ensuite une courte liste fixe : le répertoire /wp-content/uploads/ (pas de liste de répertoire), /.git/HEAD, /wp-content/debug.log et quelques noms courants de copies de wp-config.php. C'est correct si aucun d'eux ne renvoie de contenu (404 ou 403). Le programme ne teste rien d'autre et ne modifie rien.

Pour aller plus loin

Ces articles décrivent les étapes dans les panneaux de WebOké ; dans d'autres panneaux, cela fonctionne de manière similaire.

• Guide DirectAdmin 11.5: Permissions des fichiers et dossiers (chmod)
• Guide DirectAdmin 11.4: Afficher et modifier les fichiers cachés comme .htaccess
• Guide DirectAdmin 15.10: Pare-feu applicatif web
• Guide DirectAdmin 15.11: Imunify360 : scanner votre site web contre les malwares
• Bloquer des fichiers via .htaccess, par exemple plugin-googlemap2-proxy.php
• Sécurité PHP
• Renforcer WordPress (developer.wordpress.org, en anglais) : https://developer.wordpress.org/advanced-administration/security/hardening/
• En-têtes de sécurité (MDN, en anglais) : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#security