Drupal 11 est la dernière version majeure du célèbre CMS (sortie en 2024). Voici une sélection d’astuces pratiques de configuration, de performance et de durcissement pour une installation Drupal 11 en production. La plupart des opérations passent par Drush, l’outil en ligne de commande de Drupal, et par le fichier sites/default/settings.php.

Drush : la boîte à outils en ligne de commande

Drush accélère énormément l’administration au quotidien. Quelques commandes incontournables :

# Reconstruire le cache (equivalent de "Vider les caches")
drush cache:rebuild        # alias : drush cr
# Lancer le cron
drush cron
# Appliquer les mises a jour de base apres une montee de version
drush updatedb             # alias : drush updb
# Exporter / importer la configuration (workflow recommande)
drush config:export        # alias : drush cex
drush config:import        # alias : drush cim
# Obtenir un lien de connexion admin a usage unique (mot de passe oublie)
drush user:login           # alias : drush uli

Pour mettre à jour le cœur et les modules, on passe désormais par Composer, puis Drush :

composer update drupal/core-* --with-all-dependencies
drush updatedb -y
drush cache:rebuild

Protéger les hôtes de confiance (trusted_host_patterns)

Sans cette protection, Drupal est vulnérable aux attaques par en-tête Host (HTTP Host header spoofing) et affiche un avertissement dans le rapport d’état. On déclare les domaines autorisés dans settings.php (ce sont des expressions régulières, le point doit être échappé) :

$settings['trusted_host_patterns'] = [
  '^mon-site\.fr$',
  '^www\.mon-site\.fr$',
];

Drupal derrière un reverse proxy (SSL offload)

Quand un reverse proxy ou un load-balancer (HAProxy, Nginx, Varnish…) termine le HTTPS et parle à Drupal en HTTP clair, Drupal ne détecte ni le bon protocole ni la vraie IP du client. Symptômes : URLs en http://, cookies non sécurisés, et utilisateurs bloqués par le module flood (toutes les requêtes semblent venir de l’IP du proxy). On l’indique dans settings.php :

// Drupal est derriere un reverse proxy / load-balancer en SSL offload
$settings['reverse_proxy'] = TRUE;
// IP(s) de confiance du ou des proxys, vues depuis le serveur web
$settings['reverse_proxy_addresses'] = ['10.0.0.1'];

Drupal tient alors compte des en-têtes X-Forwarded-For (vraie IP client) et X-Forwarded-Proto (protocole réel) transmis par le proxy. Côté proxy, il faut évidemment envoyer ces en-têtes :

# Nginx (bloc qui transmet vers le backend Drupal)
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;

Bien régler settings.php

Quelques réglages utiles, à mettre de préférence dans un settings.local.php propre à la production :

// Repertoire de synchronisation de la configuration (hors webroot de preference)
$settings['config_sync_directory'] = '../config/sync';
// Interdire l'installation/MAJ de modules depuis l'interface (on passe par Composer)
$settings['allow_authorize_operations'] = FALSE;

Performance : cache et agrégation

En production, activez l’agrégation CSS/JS et déportez le cache vers Redis. L’agrégation se règle en une commande :

drush config:set system.performance css.preprocess 1 -y
drush config:set system.performance js.preprocess 1 -y

Pour utiliser Redis comme backend de cache (module redis installé via Composer) :

$settings['redis.connection']['interface'] = 'PhpRedis';
$settings['redis.connection']['host'] = '127.0.0.1';
$settings['cache']['default'] = 'cache.backend.redis';

Durcir la sécurité

Vérifiez régulièrement les vulnérabilités connues de vos dépendances, et verrouillez les permissions de fichiers :

# Auditer les dependances Composer (CVE connues)
composer audit
# Permissions : repertoires en 755, fichiers en 644
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
# Le fichier settings.php en lecture seule
chmod 444 sites/default/settings.php

Complétez avec le module Automatic Updates (intégré au cœur de Drupal 11 pour les correctifs de sécurité), l’authentification à deux facteurs (module TFA) et le module Security Kit (Seckit) pour les en-têtes HTTP de sécurité.

📚 À lire aussi