Sécurité Drupal, WordPress et formulaires métier : quels contrôles prioriser sur un site sensible ?

Pourquoi les sites à base de CMS concentrent le risque

Un site construit sur un CMS comme Drupal ou WordPress n'est jamais un bloc monolithique. Il additionne un cœur applicatif, des modules ou plugins tiers, un thème, des formulaires exposés au public et des intégrations avec des outils externes (CRM, emailing, analytics). Chacune de ces couches constitue une surface d'attaque : un point d'entrée potentiel pour un attaquant.

Les formulaires occupent une place particulière dans cette équation. Ils sont, par définition, ouverts à tous les visiteurs, ils acceptent des données saisies librement et ils stockent ou transmettent souvent des informations personnelles, parfois sensibles. Un formulaire mal protégé peut ainsi servir de vecteur d'injection, de canal de spam massif ou de fuite de données collectées.

Pour un directeur digital, la conséquence est simple : la sécurité d'un site CMS ne se joue pas uniquement dans le code, mais dans la gouvernance de l'ensemble — mises à jour, choix des modules, hébergement, droits d'accès et cycle de vie des données collectées.

Étape préalable : cartographier ce que votre site expose et collecte

Avant de prioriser des contrôles, il faut savoir ce qu'il y a à protéger. Cette cartographie peut être menée sans compétence technique poussée, en répondant à quelques questions :

• Quels formulaires sont exposés publiquement (contact, devis, candidature, inscription, téléchargement) et quelles données collectent-ils ?
• Où ces données sont-elles stockées : dans la base du site, envoyées par email, poussées vers un CRM, ou les trois à la fois ?
• Quels modules ou plugins tiers sont installés, lesquels sont réellement utilisés, et qui les maintient ?
• Qui dispose d'un accès au back-office, avec quels niveaux de droits, et ces comptes correspondent-ils encore à des personnes en poste ?
• Existe-t-il des contenus à accès restreint (extranet, espace membre, documents internes) dont l'exposition serait problématique ?

Cette cartographie permet de classer les composants par criticité : un plugin décoratif inactif ne présente pas le même enjeu qu'un module de formulaire qui stocke des données personnelles en base.

Niveau 1 : l'hygiène de base, à vérifier avant tout le reste

La grande majorité des compromissions de sites CMS exploite des faiblesses connues et évitables. Les contrôles suivants relèvent de l'hygiène de base : ils sont peu coûteux au regard du risque qu'ils couvrent et doivent passer en premier.

Mises à jour du cœur et des extensions

• Le cœur du CMS est-il sur une version encore supportée par son éditeur ou sa communauté ? Une version en fin de vie ne reçoit plus de correctifs de sécurité, ce qui transforme chaque nouvelle vulnérabilité publiée en risque permanent.
• Les modules et plugins sont-ils à jour, et existe-t-il un processus régulier pour appliquer les correctifs de sécurité, avec un délai de patch défini (le temps maximal toléré entre la publication d'un correctif critique et son application) ?
• Les extensions inutilisées sont-elles désinstallées, et pas seulement désactivées ? Chaque module dormant reste du code potentiellement vulnérable.

Comptes, accès et authentification

• Les comptes administrateurs sont-ils limités au strict nécessaire, nominatifs, et revus lors des départs et changements de prestataires ?
• Une authentification renforcée (mot de passe robuste, double authentification quand elle est disponible) est-elle en place pour les accès au back-office ?
• Les rôles et permissions distinguent-ils bien contribution éditoriale, administration fonctionnelle et administration technique ?

Chiffrement, sauvegardes et hébergement

• L'ensemble du site est-il servi en HTTPS, y compris les pages de formulaire et le back-office ?
• Des sauvegardes régulières existent-elles, sont-elles stockées hors du serveur de production, et ont-elles déjà été testées en restauration ?
• L'hébergement est-il maintenu (système, base de données, serveur web) et l'environnement de production est-il isolé des environnements de test ?

Niveau 2 : les contrôles spécifiques aux formulaires et contenus sensibles

Une fois l'hygiène de base assurée, les formulaires méritent une attention dédiée, car ils cumulent exposition publique et données personnelles.

Protéger le point d'entrée

• Les champs sont-ils validés côté serveur (et pas seulement dans le navigateur), pour bloquer les injections et les contenus malveillants ?
• Des mécanismes anti-spam et anti-abus (captcha, limitation du nombre de soumissions, filtrage) sont-ils en place sur les formulaires publics ?
• Les téléversements de fichiers, s'ils existent, sont-ils restreints en type et en taille, et stockés hors des répertoires exécutables ?

Maîtriser le cycle de vie des données collectées

• Le formulaire collecte-t-il uniquement les données nécessaires à sa finalité, conformément au principe de minimisation du RGPD (Règlement général sur la protection des données) ?
• Les soumissions stockées dans la base du site sont-elles purgées régulièrement, ou s'accumulent-elles depuis des années en constituant un stock de données à risque ?
• Les transmissions vers des outils tiers (CRM, emailing) sont-elles sécurisées et documentées, et sait-on qui y a accès ?
• Les notifications par email contenant des données personnelles sont-elles limitées aux destinataires légitimes ?

Contrôler les contenus à accès restreint

• Les contenus réservés (extranet, documents internes, pages non publiées) sont-ils réellement inaccessibles sans authentification, y compris via des URL directes ou l'indexation par les moteurs de recherche ?
• Les permissions d'accès à ces contenus sont-elles revues périodiquement ?

Niveau 3 : gouvernance des modules et workflow de mise à jour

Au-delà des contrôles ponctuels, c'est l'organisation dans la durée qui fait la différence entre un site qui se dégrade et un site qui reste maîtrisé.

• Inventaire vivant : tenir à jour la liste des modules, de leur rôle, de leur criticité et de leur source (communauté officielle, éditeur, développement spécifique).
• Critères de choix : avant d'ajouter une extension, vérifier qu'elle est activement maintenue, largement utilisée et couverte par le processus de sécurité de la communauté du CMS.
• Workflow de mise à jour : disposer d'un environnement de test, d'une procédure de validation avant mise en production et d'un plan de retour arrière en cas de problème.
• Veille sécurité : suivre les annonces de sécurité de Drupal ou WordPress et des extensions installées, afin de qualifier rapidement si une alerte concerne réellement votre site.
• Responsabilités claires : savoir qui, en interne ou chez un prestataire de TMA (tierce maintenance applicative), est responsable d'appliquer les correctifs et dans quel délai contractuel.

Hygiène, dette technique ou refonte : comment arbitrer

Tous les constats d'un audit de sécurité n'appellent pas la même réponse. Trois situations doivent être distinguées, car elles engagent des budgets et des décisions très différents.

Ce qui relève de l'hygiène courante

Mises à jour en retard, comptes obsolètes, absence d'anti-spam, sauvegardes non testées : ces écarts se corrigent rapidement, à coût maîtrisé, dans le cadre d'une maintenance normale. Ils constituent le premier front, celui qui réduit le plus vite le risque.

Ce qui relève de la dette technique

Un module abandonné par sa communauté, des développements spécifiques non documentés, une montée de version majeure repoussée depuis longtemps : ces sujets demandent un chantier planifié, avec un chiffrage dédié. Les ignorer revient à laisser le coût de remédiation croître avec le temps, tout en maintenant le risque.

Ce qui relève d'un arbitrage de refonte ou de maintenance renforcée

Quand le socle technique est en fin de vie, que la dette est trop profonde pour être résorbée module par module, ou que les enjeux du site (données sensibles, exposition réglementaire, rôle commercial) ont dépassé ce que l'architecture d'origine peut porter, la question n'est plus celle du correctif mais celle du socle : refonte, migration vers une version majeure supportée, ou passage à une maintenance renforcée avec engagements de délais de patch et supervision continue. Ce type d'arbitrage se prend sur la base d'un audit factuel, pas sous la pression d'une alerte isolée.

La checklist de priorisation en synthèse

• Cartographier formulaires, données collectées, modules et accès.
• Vérifier version du CMS, mises à jour de sécurité et délai de patch.
• Assainir les comptes et renforcer l'authentification du back-office.
• Contrôler HTTPS, sauvegardes testées et maintenance de l'hébergement.
• Sécuriser les formulaires : validation serveur, anti-spam, purge des soumissions, minimisation des données.
• Vérifier l'étanchéité des contenus à accès restreint.
• Formaliser gouvernance des extensions, workflow de mise à jour et responsabilités de maintenance.
• Classer les constats : hygiène courante, dette technique ou arbitrage de socle.