Sécuriser MediaWiki : permissions, anti-spam, mises à jour et WAF (guide 2026)

Sécuriser MediaWiki : permissions, anti-spam, mises à jour et WAF (guide 2026)

MediaWiki est robuste, mais un wiki public (ou même semi-public) attire vite spam, tentatives de prise de contrôle et abus de capacité. La bonne approche : réduire la surface exposée, tenir le logiciel à jour, et mettre des barrières là où ça compte (comptes, édition, liens externes, uploads).

Si vous partez de zéro côté hébergement, commencez par un déploiement propre (HTTPS + volumes + base de données) : Installer MediaWiki avec Docker Compose (prod).

1) La base : rester à jour (MediaWiki + dépendances)

La majorité des incidents « graves » viennent d’un patch manquant (core, extensions, PHP, serveur web, base de données).

Bonnes pratiques :

• Planifier une fenêtre mensuelle (au minimum) pour appliquer les mises à jour.
• Mettre en place un staging (même léger) pour tester la mise à niveau avant la prod.
• Surveiller les annonces de versions et appliquer rapidement les correctifs de sécurité.

Sur adgents.cloud, vous pouvez déployer un MediaWiki proprement, et itérer sans tout casser grâce aux sauvegardes automatiques et aux environnements qui se redéploient vite : Héberger MediaWiki sur adgents.cloud.

2) Durcissement « fichiers & secrets » (souvent oublié)

Deux objectifs :

1. empêcher l’exécution de code via un fichier téléversé,
2. protéger les secrets (DB, SMTP, clés).

À vérifier :

• LocalSettings.php : lisible par le processus PHP, mais pas lisible par tout le monde.
• Le processus PHP (ex: www-data) ne doit pas avoir d’accès en écriture sur les fichiers applicatifs (hors répertoires nécessaires).
• Le répertoire d’uploads (images/) doit être écrivible, mais ne doit pas exécuter de PHP.

Si vous exécutez MediaWiki via Docker, gardez une séparation claire :

• volumes pour la base de données,
• volume pour images/,
• configuration versionnée,
• secrets injectés via variables d’environnement (et non committés).

3) Verrouiller l’accès : lecture, édition, création de compte

Un wiki privé n’a pas les mêmes règles qu’un wiki public. L’idée : choisir explicitement votre modèle :

• wiki interne (lecture/édition réservées),
• wiki public (lecture ouverte, édition contrôlée),
• wiki communautaire (édition plus ouverte, mais anti-spam fort).

3.1 Exemple : bloquer lecture et édition aux anonymes

Dans LocalSettings.php :

// Désactiver la lecture par les anonymes
$wgGroupPermissions['*']['read'] = false;

// Désactiver l’édition par les anonymes
$wgGroupPermissions['*']['edit'] = false;

3.2 Exemple : empêcher l’ouverture de comptes (ou la limiter)

// Empêcher la création de comptes (sauf si vous autorisez explicitement un groupe)
$wgGroupPermissions['*']['createaccount'] = false;

Si votre wiki est public, vous pouvez garder l’inscription ouverte, mais protéger :

• la création de compte (CAPTCHA),
• l’ajout de liens externes (CAPTCHA ou filtre),
• les premières contributions (limitations, modération).

4) Anti-spam : ce qui marche en 2026

Le spam sur MediaWiki vise surtout :

• l’ajout massif de liens externes,
• la création automatisée de comptes,
• la surcharge serveur (robots).

Mesures efficaces (à combiner) :

4.1 CAPTCHA sur actions sensibles

Activez un mécanisme de CAPTCHA sur :

• création de compte,
• ajout de liens externes,
• édition par nouveaux comptes.

4.2 Limiter les droits des nouveaux comptes

Objectif : un compte fraîchement créé ne doit pas pouvoir vandaliser à grande échelle.

Approche simple :

• restreindre certaines actions aux utilisateurs auto-confirmés,
• renforcer la protection sur les pages les plus ciblées.

4.3 Stopper les domaines et patterns connus

Deux axes :

• liste noire de domaines (liens externes),
• règles sur titres / usernames typiques de bots.

Si vous recevez beaucoup d’attaques, ajoutez aussi :

• blocage de proxies/Tor/VPN sur les actions de modification,
• limitation de débit (reverse proxy).

5) WAF + reverse proxy : filtrer avant MediaWiki

Un WAF (Web Application Firewall) et un reverse proxy bien configurés peuvent :

• bloquer des scans automatiques,
• limiter le débit par IP,
• réduire la pression sur PHP et la base de données,
• imposer HTTPS, HSTS, et des en-têtes utiles.

Si vous avez déjà un proxy (Traefik / Nginx / Caddy), visez au minimum :

• TLS correct (certificats auto),
• redirection HTTP→HTTPS,
• rate limiting sur api.php, index.php et endpoints d’édition,
• règles pour bloquer les user agents abusifs.

Sur adgents.cloud, l’objectif est justement de vous permettre de mettre un déploiement « propre » rapidement (HTTPS, sauvegardes, scaling) et d’ajouter vos garde-fous côté proxy sans complexifier votre exploitation : MediaWiki sur adgents.cloud.

6) Uploads : le point d’entrée le plus sous-estimé

Si vous autorisez le téléversement, protégez-le :

• désactiver l’exécution de scripts dans le répertoire d’uploads,
• limiter les types de fichiers autorisés,
• fixer une taille maximale raisonnable,
• mettre une politique de droits (qui peut téléverser).

Le bon compromis pour beaucoup d’équipes : autoriser les uploads aux comptes établis, pas aux comptes fraîchement créés.

7) Sauvegardes + tests de restauration (sinon ça ne compte pas)

Pour un wiki, la sauvegarde n’est pas seulement la base : il faut aussi pouvoir restaurer vite.

À couvrir :

• base de données,
• répertoire images/,
• configuration (LocalSettings.php et extensions).

Faites un test de restauration à intervalle régulier (même sur un environnement isolé) pour valider votre procédure.

8) Une vidéo (FR) pour démarrer côté admin

Pour une prise en main rapide (installation + bases), cette vidéo en français est un bon point de départ :

Conclusion : le plan simple en 5 actions

1. Garder MediaWiki et ses extensions à jour.
2. Verrouiller lecture/édition/création de compte selon votre modèle.
3. Mettre une défense anti-spam (CAPTCHA + restrictions nouveaux comptes).
4. Ajouter reverse proxy + WAF + limitations de débit.
5. Sauvegarder et valider la restauration.

Si vous voulez aller vite et rester serein en exploitation (déploiement, sauvegardes, scaling), regardez l’offre d’hébergement : MediaWiki sur adgents.cloud.