Sécuriser une infra Drupal en 2026 : check-list

Drupal a beau être l’un des CMS les plus solides du marché — on l’utilise quotidiennement chez des clients institutionnels — il reste exposé à un écosystème PHP qui demande de la rigueur. Voici la check-list que l’on applique systématiquement sur les infras Drupal qu’on reprend ou qu’on déploie en 2026, organisée par couche.

1. La couche système

Mises à jour automatiques, vraiment

unattended-upgrades doit être installé et configuré pour les paquets de sécurité. Sur Debian 12, le fichier /etc/apt/apt.conf.d/50unattended-upgrades doit autoriser uniquement le canal Debian-Security. Ne déclenchez pas les mises à jour standard en auto, vous risquez un php-fpm qui change de version mineure et casse une extension custom à 3h du matin.

SSH durci

• Authentification par clé uniquement, jamais de mot de passe
• Port standard 22, mais derrière fail2ban + un port-knocking ou un VPN si vous voulez vraiment réduire l’exposition
• AllowUsers explicite, jamais de root direct
• 2FA via Google Authenticator ou WebAuthn pour les utilisateurs sudo

Le principe du moindre privilège pour PHP-FPM

PHP-FPM doit tourner sous un utilisateur dédié au site (jamais www-data partagé entre dix sites). Sur un serveur multi-tenant, chaque pool a son user système, son groupe, et ses chmod 750 sur les répertoires. Le compromis d’un site ne donne pas accès aux autres.

2. Le serveur web

Headers de sécurité, sans excuse

Sur nginx, dans le bloc serveur :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
add_header Content-Security-Policy "default-src 'self'; ..." always;

La CSP est l’étape la plus longue à régler proprement : Drupal embarque souvent des inline scripts. Comptez deux à trois jours de fine-tuning sur un site de taille moyenne, avec un report-uri vers un endpoint de collecte pendant la phase d’audit.

TLS moderne uniquement

TLS 1.0 et 1.1 sont morts depuis 2018, TLS 1.2 reste acceptable, TLS 1.3 en priorité. La config Mozilla intermediate est un bon compromis pour 2026. Sur les sites institutionnels, on passe en modern (TLS 1.3 only) quand l’audience est uniquement interne.

Rate-limiting au niveau nginx

Drupal a flood control côté applicatif, mais c’est trop tard si une attaque génère 10 000 requêtes par seconde. Une zone de rate-limiting nginx sur /user/login et /user/password règle 99% des bots :

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location ~ ^/(user/login|user/password) {
  limit_req zone=login burst=10 nodelay;
  ...
}

3. Drupal lui-même

Update Manager désactivé en prod

Le module Update Manager autorise les mises à jour via l’UI. Sur une prod, c’est une porte d’entrée pour tout admin compromis. Désactivez-le et gérez les updates via Composer + drush en CI/CD. Sur un site Composer-based (la norme depuis Drupal 8), c’est de toute façon le seul flow valide.

Modules de sécurité incontournables

• Security Kit : durcit headers, cookie flags, samesite
• Password Policy : impose une complexité minimale et un historique
• Login Security : limite les tentatives, lockout temporisé
• TFA : 2FA pour les comptes éditeurs et admins
• Honeypot : anti-bot sur les formulaires publics, plus discret que reCAPTCHA et sans cookies tiers

Permissions des fichiers

sites/default/files/   chmod 770, owner www-data:www-data
sites/default/settings.php   chmod 440, owner root:www-data
.htaccess sur sites/default/files/   présent et signé

Drush a une commande drush status qui vérifie les permissions critiques. Lancez-la dans votre pipeline de déploiement et faites échouer le build si elle remonte du rouge.

Composer audit en CI

À chaque push, le pipeline doit lancer :

composer audit --format=json

Ça remonte les CVE des paquets PHP. Bloquez le merge si une vulnérabilité high ou critical est détectée. Le coût : 30 secondes par build. Le bénéfice : vous découvrez les CVE avant les attaquants.

4. La base de données

MySQL/MariaDB n’est pas exposé

Bind sur 127.0.0.1 ou un socket Unix. Si vous avez besoin d’un accès distant pour un dev, c’est via SSH tunnel, pas via l’ouverture du port 3306 sur l’internet public. On a vu trop de bases MariaDB exposées avec des creds par défaut, c’est une catastrophe automatique en quelques heures.

Sauvegardes chiffrées hors site

Le rsync nightly vers un NAS local, ce n’est pas un backup, c’est une copie. Un vrai backup est :

1. Chiffré au repos (age ou gpg)
2. Stocké hors site (S3, Backblaze B2, NAS distant)
3. Testé régulièrement (restauration mensuelle dans un environnement isolé)

Sur les infras K3s qu’on opère, Velero fait le job avec un hook SQL avant snapshot, et la cible est un bucket OVH Object Storage en cross-region.

5. Le monitoring qui sert à quelque chose

Un WAF qui ne déclenche jamais d’alerte n’est pas un WAF, c’est de l’enluminure. Les indicateurs qu’on monitore activement :

• Taux d’erreurs 4xx et 5xx par endpoint
• Tentatives de login échouées par IP (alerte > 50 / heure)
• Modifications de fichiers dans core/, modules/, themes/ (AIDE ou équivalent)
• Création de nouveaux comptes utilisateurs avec rôle élevé
• Logs Drupal dblog exportés vers Loki, requêtables dans Grafana

L’alerte qui sauve une infra : un changement non planifié de hash sur les fichiers core/. C’est le signal d’un défaçage ou d’un webshell. Sur les sites les plus exposés, on déploie en lecture seule (chmod a-w sur core/ après chaque release) et tripwire ou inotify qui alerte immédiatement.

En résumé

Sécuriser Drupal en 2026, ce n’est pas une question de produit miracle, c’est un ensemble de mesures organisées par couches. Les attaquants testent toutes les portes, votre boulot est de les fermer toutes. La check-list ci-dessus n’est pas exhaustive, mais elle bloque 95% des scénarios opportunistes que l’on rencontre en mission.

Le 5% restant, c’est l’attaque ciblée — et là, c’est une autre histoire, qui passe par du Threat Modeling et des audits réguliers. C’est précisément le travail qu’on fait pour nos clients sensibles.