Chapitre 11.1 — Sécurité & hardening

⏱️ TL;DR — Au-delà de la sécurité du code (Partie 7.7), sécuriser une installation en production, c’est du hardening : mises à jour à jour (1re cause de piratage), permissions de fichiers correctes, wp-config verrouillé, comptes forts + 2FA, DISALLOW_FILE_EDIT, limiter les plugins (surface d’attaque), HTTPS, en-têtes de sécurité, et un WAF/monitoring. La plupart des piratages exploitent des plugins obsolètes ou des mots de passe faibles — pas des failles exotiques.

🎯 Objectifs

• Appliquer les mesures de durcissement essentielles.
• Comprendre les vecteurs d’attaque réels (plugins obsolètes, comptes).
• Verrouiller wp-config, fichiers, comptes.
• Situer WAF, monitoring et bonnes pratiques d’exploitation.

1. Les vraies causes de piratage

Contrairement au fantasme du « hacker génial », l’immense majorité des sites WordPress sont compromis par :

1. Plugins/thèmes obsolètes avec des failles connues (non mises à jour).
2. Mots de passe faibles / comptes admin par force brute.
3. Environnement vulnérable (PHP obsolète, hébergement mal configuré).
4. Extensions de source douteuse (nulled/piratées) contenant des backdoors.

→ La sécurité de base (mises à jour, mots de passe, sources fiables) élimine 90 % du risque. Le reste est du durcissement.

2. Verrouiller wp-config et les fichiers

• DISALLOW_FILE_EDIT : define('DISALLOW_FILE_EDIT', true); — désactive l’éditeur de code thème/plugin de l’admin (une backdoor idéale si un compte admin est compromis).
• Permissions fichiers : dossiers 755, fichiers 644, wp-config.php en 600/640. Le serveur web ne doit pas pouvoir tout écrire.
• wp-config.php hors racine web si possible, et jamais versionné (ch. 4.2).
• Sels uniques (ch. 4.2) ; les changer en cas de compromission déconnecte les attaquants.
• DISALLOW_UNFILTERED_HTML pour empêcher l’injection de HTML/JS par des rôles non-admin.

⚠️ Piège — permissions 777. Mettre des dossiers en 777 (« pour que ça marche ») rend le site écrasable par n’importe qui sur un serveur mutualisé. Jamais 777. Les bons droits (755/644) suffisent ; un upload qui échoue se règle par la propriété (owner) du fichier, pas par 777.

3. Comptes et authentification

• Mots de passe forts (WordPress en génère) ; bannir les comptes admin/mots de passe communs.
• 2FA (double authentification) sur les comptes à privilèges (via plugin).
• Moindre privilège (ch. 2.2) : peu d’admins, rôles adaptés.
• Limiter les tentatives de connexion (anti-brute-force) et éventuellement protéger/masquer wp-login.php.
• Révoquer les Application Passwords inutilisés (ch. 9.2).

4. Réduire la surface d’attaque

• Moins de plugins : chaque plugin est une surface potentielle. Supprimez (pas seulement désactivez) ceux inutilisés.
• Sources fiables uniquement : répertoire officiel, éditeurs réputés. Jamais de plugin/thème « nulled » (piraté) — ils contiennent quasi systématiquement des backdoors.
• Auditer régulièrement (Site Health, ch. 2.7 ; scanners de vulnérabilités).
• Désactiver ce qui n’est pas utilisé (XML-RPC si inutile, l’éditeur de fichiers, l’API users publique si non nécessaire).

5. Réseau, en-têtes, WAF

• HTTPS partout (redirection + HSTS).
• En-têtes de sécurité : X-Content-Type-Options: nosniff, X-Frame-Options/frame-ancestors, Content-Security-Policy (à ajuster), Referrer-Policy.
• WAF (Web Application Firewall) : au niveau hébergeur/CDN (Cloudflare, Sucuri) ou plugin (Wordfence). Bloque les attaques connues avant WordPress.
• Sauvegardes testées (ch. 2.7) : la dernière ligne de défense en cas de compromission.
• Monitoring : détection de fichiers modifiés, journaux, alertes.

💡 Pour un dev React — Le hardening WordPress rejoint vos réflexes DevSecOps : dépendances à jour (comme npm audit), secrets hors du code, permissions minimales, en-têtes de sécurité, WAF/CDN devant l’app. La spécificité WordPress est l’écosystème de plugins (surface énorme) : la discipline « moins de dépendances, à jour, de source fiable » y est vitale. Un audit de sécurité + durcissement est une prestation claire et facturable (Partie 13).

📚 Aller plus loin — Le top OWASP (injection, XSS, CSRF, contrôle d’accès défaillant…) se retrouve intégralement dans WordPress. Les protections du code (Partie 7.7 : sanitize/escape/nonce/capability, $wpdb->prepare) couvrent l’essentiel côté développement ; le hardening couvre l’exploitation. Les deux sont nécessaires.

✏️ Exercices

1. Quelles sont les deux causes les plus fréquentes de piratage d’un site WordPress ?
2. Pourquoi DISALLOW_FILE_EDIT est-il recommandé en production ?
3. Un upload échoue ; un tutoriel conseille chmod 777. Que faites-vous à la place ?

🧠 Quiz de révision

Chapitre suivant : Performance & caching.