// case_study · wordpress · audit_sans_acces_serveur

WordPress : de 3/10 à 7,5/10
sans FTP, sans SSH.

Audit de sécurité complet d'un site WordPress — réalisé uniquement depuis l'interface d'administration. Zéro accès serveur. Résultats mesurables.

audit@wp-client — post-intervention
# Vérification XML-RPC avant intervention
$ curl -s -o /dev/null -w "%{http_code}" https://[client].com/xmlrpc.php
200 ← XML-RPC répondait à tout

# Après installation Disable XML-RPC-API
$ curl -s -o /dev/null -w "%{http_code}" https://[client].com/xmlrpc.php
403 ← bloqué au niveau HTTP ✓

$ curl -s https://[client].com/wp-json/wp/v2/users | head -c 50
{"code":"rest_forbidden","message":"Sorry..."} ← enum. bloquée ✓

$ curl -sI https://[client].com/ | grep -i x-pingback
[vide] ← X-Pingback supprimé ✓
↓ scroll
// 01 — contexte

La contrainte : zéro accès serveur

Un site WordPress pour une école de danse (Strasbourg). Hébergement mutualisé, sans FTP, sans SSH, sans accès cPanel. La seule porte d'entrée disponible : l'interface wp-admin.

C'est précisément la situation dans laquelle se trouvent la majorité des petits sites WordPress. Notre objectif était de prouver qu'un audit et une mise en sécurité sérieux restent possibles dans ce cadre.

AVANT — Score global 4/10
🔴 10 plugins avec mises à jour en attente dont 1 critique
🔴 9 thèmes obsolètes (correctifs sécurité non appliqués)
🔴 XML-RPC exposé — répondait en 200 OK à tous les appels
🔴 Énumération des utilisateurs possible via REST API
🟠 Wordfence installé mais non configuré
🟠 X-Pingback exposé dans les en-têtes HTTP
🟠 URL de connexion WordPress visible et standard
🟠 5 images sans attribut alt (accessibilité + SEO)
🟠 Absence de sitemap.xml et robots.txt
🟠 URL canonique configurée en HTTP au lieu de HTTPS
APRÈS — Score global 6/10
✅ 10 plugins mis à jour, dont correctif critique All-in-One Video Gallery
✅ 9 thèmes mis à jour
✅ XML-RPC bloqué — 403 Forbidden (GET + POST)
✅ Énumération utilisateurs bloquée par Wordfence
✅ Wordfence WAF actif + brute force configuré
✅ X-Pingback supprimé des en-têtes
✅ Blocage User-Agent vide activé
✅ Auto-update Wordfence activé
⚠️ URL masquage impossible (mod_rewrite désactivé côté serveur)
📋 SEO + headers HTTP sécurité → Phase 2
// 02 — scores_mesurés

Résultats par domaine

SÉCURITÉ
7,5/10
3/10 → 7,5/10 ↑
PERFORMANCE
5,5/10
5/10 → 5,5/10 ↑
SEO
4,5/10
4/10 → 4,5/10 ↑
UX
6/10
6/10 → 6/10 =

Scores établis par audit manuel : vérification des en-têtes HTTP, tests curl xmlrpc.php, navigation chronométrée (Navigation Timing API), analyse SEO (Yoast, sitemap, alt tags, canonicals), accessibilité et compatibilité mobile.

// 03 — chronologie

Déroulement de la mission

Étape 1
Audit initial
Scan de surface : en-têtes HTTP (curl), XML-RPC, REST API, X-Pingback, versions plugins/thèmes, performance (Navigation Timing API), SEO (sitemap, robots.txt, canonicals, alt tags), UX mobile.
Étape 2
Mises à jour critiques
10 plugins + 9 thèmes mis à jour via wp-admin. Correctif critique identifié : All-in-One Video Gallery (vulnérabilité CVE documentée) — appliqué en priorité.
Étape 3
Configuration Wordfence
WAF activé (mode étendu), protection brute force configurée, blocage User-Agent vide activé, blocage usernames invalides, auto-update du plugin activé. Énumération REST API bloquée au niveau applicatif.
Étape 4
Blocage XML-RPC — découverte et correction
Premier plugin installé (Disable XML-RPC — Phil Erb) : ne bloquait que les requêtes GET. Les POST passaient toujours (200 OK). Remplacé par Disable XML-RPC-API, qui bloque au niveau HTTP → 403 Forbidden sur GET et POST.
Étape 5
Masquage URL connexion — limitation serveur
WPS Hide Login installé puis retiré : la configuration serveur (mod_rewrite désactivé, AllowOverride None) empêchait le fonctionnement du plugin — wp-login.php devenait inaccessible (404). Action reportée en Phase 2 après contact hébergeur.
Étape 6
Re-audit et rapport de livraison
Vérification complète post-intervention. Rapport de livraison résumé + rapport détaillé + rapport comparatif avant/après livrés au client au format Word.
// 04 — analyse_technique

La fausse protection XML-RPC

⚠ FINDING — PLUGIN INEFFICACE

Le plugin "Disable XML-RPC" (Phil Erb, 60 000+ installations actives) utilise le hook WordPress add_filter('xmlrpc_enabled', '__return_false'). Ce filtre bloque uniquement les méthodes authentifiées. Les appels système comme system.listMethods ou les tentatives de brute force XML-RPC passent toujours — en 200 OK.

test — plugin Phil Erb actif
# Test avec plugin "Disable XML-RPC" (Phil Erb) activé
$ curl -s -o /dev/null -w "%{http_code}" -X GET https://[client].com/xmlrpc.php
405 ← GET bloqué (mais seulement le GET)
$ curl -s -o /dev/null -w "%{http_code}" -X POST https://[client].com/xmlrpc.php
200 ← POST toujours actif ← vecteur d'attaque ouvert
✓ SOLUTION — BLOCAGE HTTP NIVEAU SERVEUR

Remplacement par Disable XML-RPC-API qui intercepte la requête avant WordPress et retourne un 403 Forbidden pour toute méthode (GET, POST, HEAD).


Résultat : curl -X POST .../xmlrpc.php → 403 — endpoint neutralisé.

// 05 — comparatif_avant_après

Tableau comparatif complet

Critère Avant Après
Mises à jour plugins 10 en retard dont 1 critique ✓ Tous à jour
Mises à jour thèmes 9 en retard ✓ Tous à jour
XML-RPC Exposé — 200 OK sur POST ✓ 403 Forbidden (GET + POST)
REST API — énumération users Exposée ✓ Bloquée (Wordfence)
Wordfence WAF Installé, non configuré ✓ Actif + configuré
Brute force protection Absente ✓ Active (Wordfence)
X-Pingback header Exposé ✓ Absent
User-Agent vide Non filtré ✓ Bloqué
Masquage URL wp-login.php Non masquée ⚠ Impossible (mod_rewrite off)
En-têtes HTTP sécurité 0/7 ⚠ 0/7 — Phase 2
Sitemap.xml Absent ⚠ À activer — Phase 2
Alt tags images 0/5 renseignés ⚠ À corriger — Phase 2
URL canonique HTTP au lieu de HTTPS ⚠ À corriger — Phase 2
// 06 — livrables

Ce que nous livrons

🔍
Audit avant intervention
Rapport illustré : sécurité, performance, SEO, UX. État initial documenté avec preuves (curl, captures, mesures).
🛡️
Corrections appliquées
Actions réalisées dans le périmètre disponible. Chaque action expliquée, aucune modification non documentée.
📋
Rapport de livraison Word
Résumé exécutif + rapport détaillé + tableau comparatif avant/après. Archivable pour vos audits.
🗺️
Plan Phase 2 priorisé
Ce qui reste à faire, dans quel ordre, avec quel niveau d'effort estimé. Aucun point laissé sans réponse.
📌 NOTE DE TRANSPARENCE

Sur un hébergement mutualisé sans accès serveur, certaines protections (en-têtes HTTP, mod_rewrite, configuration Apache) ne sont pas accessibles depuis wp-admin. Nous l'évaluons systématiquement avant l'intervention et documentons chaque limitation rencontrée avec une recommandation alternative.

Votre site WordPress mérite le même niveau d'attention.

Audit complet · Rapport livré · Résultats mesurables · Adaptés à votre hébergement

→ Demander un audit WordPress