Sécuriser WordPress au-delà des extensions : 12 réglages serveur et wp-config

Les extensions de sécurité sont utiles, mais elles ont une limite claire : elles s'exécutent à l'intérieur de WordPress, donc seulement après que la requête a déjà atteint PHP. Les mesures les plus solides se trouvent plus bas — au niveau du serveur web et dans wp-config.php, là où une extension n'a pas accès. Ce sont des réglages que l'on fait une seule fois ; ils restent actifs en silence et n'alourdissent pas le site.

Voici 12 éléments concrets que vous pouvez vérifier vous-même ou demander à votre hébergeur. Ils ne remplacent pas le bon sens (mots de passe solides, mises à jour à jour), mais ils relèvent nettement la barre pour quiconque tente d'entrer. Et un avertissement honnête : si quelqu'un vous promet un site « impossible à pirater », fuyez — la sécurité, c'est des couches, pas une case à cocher.

Des permissions de fichiers qui ne laissent pas de portes ouvertes

Les mauvaises permissions comptent parmi les problèmes les plus fréquents. La règle simple :

• répertoires : 755
• fichiers : 644
• wp-config.php : 600 (ou 640), lisible uniquement par l'utilisateur du serveur

Jamais 777 sur quoi que ce soit — cela veut dire « tout le monde peut écrire ». Vérifiez aussi le propriétaire des fichiers : tout doit appartenir à l'utilisateur sous lequel PHP tourne, pas à root. Bon signe : WordPress lui-même ne devrait pas pouvoir modifier les fichiers de thème directement — s'il le peut, un attaquant qui compromet un compte le peut aussi. wp-config.php mérite un traitement à part, car il contient les identifiants de la base de données.

wp-config.php — c'est là que tout se joue

Ce fichier est le cœur de l'installation. Quelques lignes qui comptent :

• Des clés et des sels (salts) uniques, générés depuis le service officiel WordPress — ils invalident les sessions volées.
• define('DISALLOW_FILE_EDIT', true); — retire l'éditeur de thèmes/extensions de l'admin, pour que personne n'injecte de code depuis un compte compromis.
• define('FORCE_SSL_ADMIN', true); — force le HTTPS dans l'administration.
• define('WP_DEBUG', false); et WP_DEBUG_DISPLAY désactivé en production, pour que les erreurs n'exposent pas les chemins du serveur.

En option, déplacez wp-config.php un niveau au-dessus de la racine publique et changez le préfixe des tables de wp_ vers le vôtre. Pas des solutions miracles, mais elles réduisent la surface d'attaque.

Règles au niveau du serveur web (Apache / Nginx)

C'est ici que vous bloquez l'accès avant même que PHP démarre.

• Interdisez l'accès direct aux fichiers sensibles : wp-config.php, .htaccess, readme.html, xmlrpc.php (si vous n'utilisez pas XML-RPC).
• Désactivez le listage des répertoires (Options -Indexes sur Apache), pour que personne ne parcoure vos dossiers.
• Le plus important : coupez l'exécution de PHP dans wp-content/uploads. Si un attaquant parvient à téléverser un fichier .php déguisé, sans exécution là il devient inoffensif.

Sur Nginx ce sont des blocs location ; sur Apache, des règles dans .htaccess ou la config. En hébergement mutualisé, demandez au support de les appliquer — c'est une demande normale.

En-têtes de sécurité — des réponses qui dictent les règles au navigateur

Les en-têtes HTTP n'empêchent pas un piratage côté serveur, mais ils ferment beaucoup d'attaques côté navigateur (clickjacking, sniffing de contenu, retour au HTTP). À définir :

• Strict-Transport-Security (HSTS) — oblige le navigateur à n'utiliser que le HTTPS.
• X-Content-Type-Options : nosniff — empêche de deviner le type de fichier.
• X-Frame-Options : SAMEORIGIN (ou CSP frame-ancestors) — anti-clickjacking.
• Referrer-Policy et Permissions-Policy — limitent ce qui fuit et quelles API du navigateur sont autorisées.

Définissez-les au niveau du serveur ou via les règles d'en-têtes de votre plateforme. Vous pouvez vérifier le résultat avec n'importe quel scanner d'en-têtes public et gratuit.

Base de données, comptes et maintenance

La dernière couche relève de l'hygiène :

• L'utilisateur de la base de données ne doit avoir que les droits nécessaires sur sa base — pas un compte root global.
• Pas de nom d'utilisateur « admin », et des mots de passe longs et uniques ; idéalement, une authentification à deux facteurs sur les comptes d'administration.
• Gardez PHP et WordPress dans une version supportée — beaucoup de failles viennent de logiciels anciens, pas d'attaques sophistiquées.
• Une sauvegarde automatique, testée, stockée ailleurs que sur le serveur.

Voilà à quoi ressemble une installation prise au sérieux chez MPO Web Studio : nous livrons des sites déjà sécurisés, à distance, partout dans le pays, avec ces réglages faits dès le départ. Si vous voulez un avis sur votre site actuel, écrivez-nous sur WhatsApp — nous vous dirons honnêtement ce qui mérite d'être changé.