Comment proteger votre site Drupal contre les injections SQL en 7 etapes

Les injections SQL figurent dans le Top 3 de l'OWASP depuis plus de 15 ans, et pour cause : elles permettent a un attaquant de lire, modifier ou supprimer des donnees dans votre base de donnees, et dans les cas les plus graves, d'executer du code arbitraire sur votre serveur. Les CMS comme Drupal, malgre leurs couches d'abstraction, ne sont pas immunises — la recente vulnerabilite CVE-2026-9082 en est la preuve concrete.

Ce guide vous presente 7 etapes actionnables pour proteger votre site Drupal contre les injections SQL, que vous utilisiez PostgreSQL ou MySQL comme moteur de base de donnees. Chaque etape est accompagnee de commandes, d'exemples de configuration et de recommandations pratiques.

— Etape 1 : Auditer votre installation Drupal

Avant de proteger votre site Drupal contre les injections SQL, vous devez connaitre precisement l'etat de votre installation. Un audit initial permet d'identifier votre version de Drupal, le moteur de base de donnees utilise, les modules installes et les eventuelles vulnerabilites existantes.

Verifier votre version de Drupal

Connectez-vous en SSH a votre serveur et executez les commandes suivantes avec Drush (l'outil en ligne de commande de Drupal) :

# Verifier la version de Drupal
drush status --field=drupal-version

# Identifier le moteur de base de donnees
drush sql:cli --extra="SELECT version();"

# Lister tous les modules et leur statut de securite
drush pm:security

Identifier le moteur de base de donnees

Verifiez dans votre fichier settings.php quel driver de base de donnees est configure :

# Localiser et inspecter settings.php
grep -n "driver" sites/default/settings.php

# Resultat attendu pour PostgreSQL :
# 'driver' => 'pgsql',

# Resultat attendu pour MySQL :
# 'driver' => 'mysql',

Si vous utilisez PostgreSQL, votre site est directement expose a des vulnerabilites comme CVE-2026-9082. Poursuivez ce guide avec une attention particuliere aux etapes 3 et 4.

Scanner les vulnerabilites existantes

Utilisez le module Security Review de Drupal pour une premiere evaluation automatisee de la securite de votre installation :

# Installer et executer Security Review
composer require drupal/security_review
drush en security_review
drush secrev

— Etape 2 : Mettre a jour le core et les modules

La mise a jour est la premiere et la plus importante ligne de defense contre les injections SQL. La majorite des vulnerabilites exploitees sont des failles pour lesquelles un correctif existe deja. Le delai entre la publication du patch et l'exploitation active se reduit : pour CVE-2026-9082, il etait de seulement 48 heures.

Mettre a jour via Composer

# Mettre a jour le core Drupal
composer update drupal/core "drupal/core-*" --with-all-dependencies

# Verifier les mises a jour de securite disponibles
composer audit

# Mettre a jour tous les modules contribues
composer update --with-all-dependencies

# Appliquer les mises a jour de base de donnees
drush updatedb

# Vider les caches
drush cache:rebuild

Automatiser les alertes de securite

Configurez des notifications automatiques pour etre prevenu immediatement lorsqu'une mise a jour de securite est disponible :

• ▸ Abonnez-vous a la mailing list de securite Drupal sur drupal.org/security
• ▸ Activez le module Update Manager dans Drupal pour recevoir des alertes dans le back-office
• ▸ Integrez composer audit dans votre pipeline CI/CD pour bloquer les deploiements contenant des dependances vulnerables
• ▸ Utilisez un outil de veille comme Dependabot ou Renovate pour generer automatiquement des pull requests de mise a jour

— Etape 3 : Configurer un WAF (Web Application Firewall)

Un WAF constitue votre premiere ligne de defense perimetrique contre les injections SQL. Il analyse les requetes HTTP entrantes et bloque celles qui contiennent des patterns malveillants avant qu'elles n'atteignent votre application Drupal. Meme si vous avez patche votre installation, un WAF protege contre les zero-days futurs.

Configurer ModSecurity avec le CRS OWASP

ModSecurity, combine avec le jeu de regles OWASP Core Rule Set (CRS), offre une protection solide contre les injections SQL :

# Installation ModSecurity pour Apache
sudo apt install libapache2-mod-security2
sudo cp /etc/modsecurity/modsecurity.conf-recommended \
        /etc/modsecurity/modsecurity.conf

# Activer le mode blocage (pas seulement detection)
# Editer /etc/modsecurity/modsecurity.conf
SecRuleEngine On

# Installer OWASP CRS
cd /etc/modsecurity
sudo git clone https://github.com/coreruleset/coreruleset.git
sudo cp coreruleset/crs-setup.conf.example crs-setup.conf

# Activer les regles anti-SQLi (deja incluses dans le CRS)
# Fichier: /etc/modsecurity/coreruleset/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf

Regles Nginx specifiques a Drupal

Si vous utilisez Nginx, ajoutez ces regles dans votre bloc server pour bloquer les tentatives d'injection SQL les plus courantes :

# Bloc server Nginx - regles anti-SQLi pour Drupal
location / {
    # Bloquer les patterns d'injection SQL courants
    if ($query_string ~* "(union|select|insert|update|delete|drop).*
        (from|into|table|where|set)" ) {
        return 403;
    }

    # Bloquer les tentatives specifiques a PostgreSQL
    if ($query_string ~* "(pg_catalog|information_schema|
        pg_shadow|::text|COPY\s+TO)" ) {
        return 403;
    }

    # Bloquer les commentaires SQL
    if ($query_string ~* "(\/\*|\*\/|--|;)" ) {
        return 403;
    }
}

Important : testez soigneusement ces regles en mode detection avant de passer en mode blocage. Certaines fonctionnalites legitimes de Drupal (comme le module Search) peuvent generer des faux positifs. Ajustez les regles en fonction des specificites de votre site.

— Etape 4 : Durcir la configuration PostgreSQL / MySQL

Le principe du moindre privilege applique a votre base de donnees est l'un des controles de securite les plus efficaces contre les injections SQL. Meme si un attaquant parvient a injecter du SQL, les degats seront limites si le compte de base de donnees utilise par Drupal ne dispose que des permissions strictement necessaires.

Hardening PostgreSQL pour Drupal

-- Creer un utilisateur Drupal avec permissions minimales
CREATE USER drupal_app WITH PASSWORD 'mot_de_passe_fort_ici';

-- Accorder uniquement les permissions necessaires
GRANT CONNECT ON DATABASE drupal_db TO drupal_app;
GRANT USAGE ON SCHEMA public TO drupal_app;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES
    IN SCHEMA public TO drupal_app;
GRANT USAGE, SELECT ON ALL SEQUENCES
    IN SCHEMA public TO drupal_app;

-- INTERDIR les operations dangereuses
REVOKE CREATE ON SCHEMA public FROM drupal_app;
REVOKE ALL ON DATABASE drupal_db FROM PUBLIC;

-- Bloquer l'acces aux fonctions systeme
REVOKE EXECUTE ON FUNCTION pg_read_file(text)
    FROM drupal_app;
REVOKE EXECUTE ON FUNCTION pg_ls_dir(text)
    FROM drupal_app;

-- Configurer pg_hba.conf pour restreindre les connexions
# local   drupal_db   drupal_app   scram-sha-256
# host    drupal_db   drupal_app   127.0.0.1/32   scram-sha-256

Hardening MySQL / MariaDB pour Drupal

-- Creer un utilisateur avec permissions minimales
CREATE USER 'drupal_app'@'localhost'
    IDENTIFIED BY 'mot_de_passe_fort_ici';

-- Permissions strictement necessaires
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP,
    INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES
    ON drupal_db.* TO 'drupal_app'@'localhost';

-- INTERDIR FILE et SUPER (empechent l'ecriture de fichiers)
-- Ces permissions ne doivent JAMAIS etre accordees a Drupal

-- Desactiver LOAD DATA LOCAL INFILE
-- Dans my.cnf :
-- [mysqld]
-- local-infile=0

FLUSH PRIVILEGES;

Point cle : ne donnez jamais les permissions SUPERUSER (PostgreSQL) ou SUPER / FILE (MySQL) au compte utilise par Drupal. Ces permissions transforment une injection SQL en execution de code systeme.

— Etape 5 : Utiliser correctement la Database API de Drupal

Si vous developpez des modules custom pour Drupal, la maniere dont vous interagissez avec la base de donnees est determinante. La Database API de Drupal offre des mecanismes de securite integres, mais seulement si vous les utilisez correctement.

Bonnes pratiques de code

// MAUVAIS : injection SQL possible
$result = \Drupal::database()->query(
  "SELECT * FROM {users} WHERE name = '" . $name . "'"
);

// BON : requete parametree avec placeholders
$result = \Drupal::database()->query(
  "SELECT * FROM {users} WHERE name = :name",
  [':name' => $name]
);

// ENCORE MIEUX : utiliser le query builder
$result = \Drupal::database()->select('users', 'u')
  ->fields('u', ['uid', 'name', 'mail'])
  ->condition('u.name', $name)
  ->execute()
  ->fetchAll();

// POUR LES CONDITIONS DYNAMIQUES : utiliser db_like()
$result = \Drupal::database()->select('node_field_data', 'n')
  ->fields('n', ['nid', 'title'])
  ->condition('n.title', '%' . \Drupal::database()
    ->escapeLike($search_term) . '%', 'LIKE')
  ->execute();

Les regles d'or pour le code Drupal securise :

• ▸ Jamais de concatenation de chaines dans les requetes SQL. Utilisez toujours les placeholders (:name) ou le query builder.
• ▸ Privilegiez le query builder (db_select, db_insert) plutot que les requetes SQL brutes. Il gere automatiquement l'echappement.
• ▸ Utilisez escapeLike() pour les clauses LIKE, car les placeholders ne protegent pas contre les caracteres speciaux de LIKE (%, _).
• ▸ Validez les entrees cote serveur en plus de l'utilisation de requetes parametrees. Utilisez la Form API de Drupal avec des validateurs stricts.

— Etape 6 : Tester regulierement avec des outils de securite

Les tests de securite ne doivent pas etre un evenement ponctuel, mais un processus continu integre a votre cycle de developpement. Plusieurs outils permettent de detecter les vulnerabilites d'injection SQL dans votre installation Drupal.

Outils recommandes

Exemple de test avec sqlmap

# Scanner un formulaire Drupal pour les injections SQL
# ATTENTION : a utiliser uniquement sur VOS propres sites
sqlmap -u "https://votre-site.fr/contact?name=test" \
       --forms \
       --batch \
       --level=3 \
       --risk=2 \
       --dbms=PostgreSQL \
       --output-dir=./sqlmap-results

# Scanner un endpoint specifique avec cookies de session
sqlmap -u "https://votre-site.fr/search?keys=test" \
       --cookie="SESS_drupal=votre_cookie" \
       --level=5 \
       --risk=3 \
       --tamper=space2comment \
       --dbms=PostgreSQL

Frequence recommandee : executez des scans automatises apres chaque mise a jour du core ou des modules, et planifiez un test d'intrusion professionnel au minimum une fois par an, ou apres chaque modification majeure de votre infrastructure.

— Etape 7 : Mettre en place un monitoring continu

La derniere etape, mais certainement pas la moins importante, est la mise en place d'un systeme de surveillance continue. Meme avec toutes les protections en place, de nouvelles vulnerabilites seront decouvertes. Le monitoring vous permet de detecter et reagir rapidement aux tentatives d'exploitation.

Configurer la journalisation avancee

# PostgreSQL : activer le log des requetes suspectes
# Dans postgresql.conf :
log_statement = 'all'          # ou 'mod' pour INSERT/UPDATE/DELETE
log_min_duration_statement = 1000  # logger les requetes > 1s
log_line_prefix = '%t [%p] %u@%d '

# Surveiller les acces aux tables systeme
# Creer une alerte pour les requetes vers pg_catalog

# Apache/Nginx : activer le log des POST bodies
# Nginx : ajoutez dans le bloc http :
log_format postdata '$remote_addr - $request_body';

# Drupal : activer le module Syslog pour centraliser les logs
drush en syslog

Alertes en temps reel

Configurez des alertes automatiques pour etre notifie immediatement en cas de tentative d'injection SQL :

• ▸ SIEM (Wazuh, ELK, Splunk) : integrez les logs de votre WAF, de votre serveur web et de PostgreSQL dans un SIEM pour une vue centralisee et des correlations automatiques.
• ▸ Fail2ban : configurez des regles pour bannir automatiquement les IP qui envoient des requetes contenant des patterns d'injection SQL.
• ▸ Monitoring d'integrite : utilisez AIDE ou Tripwire pour detecter toute modification non autorisee des fichiers Drupal (backdoor, webshell).
• ▸ Drupal Watchdog : surveillez les logs internes de Drupal (/admin/reports/dblog) pour les erreurs de base de donnees et les tentatives de connexion echouees.

Exemple de regle Fail2ban pour Drupal

# /etc/fail2ban/filter.d/drupal-sqli.conf
[Definition]
failregex = ^<HOST>.*"(GET|POST).*
    (union.*select|insert.*into|
    pg_catalog|information_schema|
    COPY.*TO.*PROGRAM).*HTTP/
ignoreregex =

# /etc/fail2ban/jail.d/drupal-sqli.conf
[drupal-sqli]
enabled  = true
port     = http,https
filter   = drupal-sqli
logpath  = /var/log/nginx/access.log
maxretry = 3
findtime = 300
bantime  = 86400
action   = %(action_mwl)s

Conclusion : la securite est un processus, pas un etat

Proteger votre site Drupal contre les injections SQL n'est pas une action ponctuelle mais un processus continu. Les 7 etapes presentees dans ce guide constituent un socle solide de securisation, mais elles doivent etre maintenues et ajustees dans le temps, au fur et a mesure que de nouvelles menaces emergent.

La recente vulnerabilite CVE-2026-9082 a demontre que meme les couches d'abstraction les plus matures peuvent echouer. La cle est de ne jamais reposer sur une seule ligne de defense : combinez les mises a jour rapides (etape 2), la protection perimetrique (etape 3), le hardening de la base de donnees (etape 4) et le monitoring continu (etape 7) pour creer une posture de securite resiliente.

Rappelez-vous : le cout d'un audit de securite et de la mise en place de ces protections est toujours infiniment inferieur au cout d'une compromission — qu'il s'agisse de la perte de donnees, des amendes RGPD/NIS2, ou de l'atteinte a votre reputation.