Comment proteger Metabase contre les injections SQL zero-day en 7 etapes

— Pourquoi Metabase est une cible privilegiee

Metabase est l'un des outils de business intelligence open-source les plus deployes au monde, avec plus de 50 000 organisations utilisatrices. En France, il est largement adopte dans les administrations publiques, les startups et les PME pour sa simplicite de deploiement — un conteneur Docker et quelques clics suffisent — et son interface intuitive de visualisation de donnees.

Mais cette accessibilite masque un risque fondamental : Metabase est, par conception, un point d'acces direct aux bases de donnees. Il se connecte a PostgreSQL, MySQL, MongoDB, BigQuery ou tout autre moteur avec des identifiants a privileges eleves. Quand une vulnerabilite permet de contourner les controles d'acces de Metabase, l'attaquant herite de ces privileges — et peut extraire l'integralite des donnees accessibles.

En aout 2026, une vulnerabilite zero-day d'injection SQL dans Metabase a ete exploitee pour extraire 31 544 lignes de donnees du cloud numerique de l'Etat (DINUM). Ce n'est pas un incident isole : en 2023, la CVE-2023-38646 permettait l'execution de code a distance sur des milliers d'instances exposees. Le pattern est recurrent, et les 7 etapes qui suivent sont concues pour vous proteger — y compris contre des vulnerabilites qui n'ont pas encore ete decouvertes.

— Etape 1 : Mettre a jour Metabase immediatement

La premiere mesure, la plus urgente, est de verifier que votre instance Metabase est a jour. Chaque version majeure de Metabase a corrige des vulnerabilites critiques d'injection SQL ou d'execution de code a distance. Si vous n'avez pas mis a jour depuis plusieurs mois, votre instance est tres probablement vulnerable a au moins une faille connue.

Verifier votre version :

# Via l'API (accessible sans authentification sur certaines versions)
curl -s https://votre-metabase.example.com/api/health
curl -s https://votre-metabase.example.com/api/session/properties | jq '.version'

# Via Docker
docker inspect metabase/metabase | jq '.[0].Config.Labels'

Mettre a jour :

# Docker Compose
docker compose pull metabase
docker compose up -d metabase

# JAR standalone
wget https://downloads.metabase.com/latest/metabase.jar
java -jar metabase.jar

Activez egalement les mises a jour automatiques si votre infrastructure le permet. Pour les environnements Docker, configurez un pipeline CI/CD qui detecte les nouvelles versions et les deploie apres validation sur un environnement de test.

— Etape 2 : Configurer les requetes parametrees

L'injection SQL exploite la concatenation naive de donnees utilisateur dans les requetes SQL. La parade fondamentale est l'utilisation de requetes parametrees (aussi appelees "prepared statements") qui separent le code SQL des donnees. Metabase supporte les requetes parametrees via sa syntaxe de variables.

Mauvaise pratique (vulnerable) :

-- VULNERABLE : concatenation directe
SELECT * FROM users WHERE email = '{{email}}'
-- Un attaquant peut injecter : ' OR 1=1 --

Bonne pratique (securisee) :

-- SECURISE : variable Metabase avec type defini
SELECT * FROM users WHERE email = {{email}}
-- Declarez 'email' comme type "Text" dans l'editeur de variables
-- Metabase l'echappera automatiquement

Auditez toutes vos requetes natives (celles ecrites en SQL pur dans Metabase). Recherchez les patterns '{{variable}}' avec des guillemets autour des variables — ce sont des indicateurs de requetes non parametrees. Remplacez-les par la syntaxe de variables typees de Metabase. Pour les requetes complexes, utilisez des vues SQL materialisees cote base de donnees plutot que des requetes natives dans Metabase.

— Etape 3 : Deployer un WAF avec regles anti-SQLi

Un Web Application Firewall (WAF) place devant Metabase agit comme un filtre qui analyse chaque requete HTTP entrante et bloque celles qui contiennent des patterns d'injection SQL. C'est votre premiere ligne de defense contre les exploits zero-day — meme si la faille dans Metabase n'est pas encore corrigee, le WAF peut bloquer les tentatives d'exploitation.

Configuration Nginx + ModSecurity :

# /etc/nginx/conf.d/metabase.conf
server {
    listen 443 ssl;
    server_name metabase.example.com;

    # Activer ModSecurity
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsecurity/main.conf;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # Limiter la taille des requetes
        client_max_body_size 10m;

        # Rate limiting
        limit_req zone=metabase burst=20 nodelay;
    }
}

# /etc/nginx/modsecurity/custom-rules.conf
# Bloquer les patterns d'injection SQL courants
SecRule ARGS "@rx (\b(union|select|insert|update|delete|drop|exec|execute)\b.*\b(from|into|table|database)\b)" \
    "id:100001,phase:2,deny,status:403,msg:'SQL Injection attempt blocked'"

SecRule ARGS "@rx (--|;|\/\*|\*\/|@@|char\(|nchar\(|varchar\()" \
    "id:100002,phase:2,deny,status:403,msg:'SQL Injection special chars blocked'"

Si vous utilisez un CDN ou un hebergeur cloud, activez les regles anti-SQLi fournies nativement : Cloudflare WAF (regles OWASP incluses dans le plan Pro), AWS WAF avec les regles gerees AWSManagedRulesSQLiRuleSet, ou Azure Front Door avec le rule set OWASP 3.2. Ces solutions sont plus simples a deployer que ModSecurity et offrent une protection immediate.

— Etape 4 : Appliquer le principe du moindre privilege

Meme si un attaquant parvient a exploiter une faille dans Metabase, les degats seront limites si l'utilisateur de base de donnees utilise par Metabase n'a acces qu'aux donnees strictement necessaires. C'est le principe du moindre privilege : chaque composant ne doit avoir que les permissions minimales requises pour fonctionner.

Configuration PostgreSQL :

-- Creer un utilisateur dedie a Metabase (lecture seule)
CREATE USER metabase_reader WITH PASSWORD 'mot_de_passe_complexe';

-- N'accorder l'acces qu'aux tables necessaires
GRANT CONNECT ON DATABASE production TO metabase_reader;
GRANT USAGE ON SCHEMA public TO metabase_reader;

-- Lecture seule sur les tables de reporting uniquement
GRANT SELECT ON TABLE reporting_ventes, reporting_clients,
    reporting_kpis TO metabase_reader;

-- JAMAIS : GRANT ALL PRIVILEGES
-- JAMAIS : acces au schema information_schema ou pg_catalog
-- JAMAIS : droits sur les tables contenant des donnees sensibles
--          (utilisateurs, mots de passe, tokens)

Creez un schema dedie au reporting dans votre base de donnees, avec des vues materialisees qui ne contiennent que les colonnes necessaires. De cette maniere, meme une extraction complete du schema Metabase ne reveelerait que des donnees agregees, sans acces aux tables sources contenant les donnees personnelles ou les identifiants.

— Etape 5 : Segmenter le reseau et restreindre les acces

La majorite des instances Metabase compromises dans les incidents recents partageaient un point commun : elles etaient directement accessibles depuis Internet, sans VPN ni reverse proxy authentifie. C'est l'equivalent de laisser la porte de votre coffre-fort ouverte et compter sur la serrure interieure pour proteger son contenu.

Architecture recommandee :

# docker-compose.yml securise
services:
  metabase:
    image: metabase/metabase:latest
    # NE PAS exposer le port directement
    # ports:
    #   - "3000:3000"  # DANGEREUX
    networks:
      - internal
    environment:
      MB_JETTY_HOST: "0.0.0.0"
      MB_JETTY_PORT: "3000"
      # Forcer HTTPS
      MB_REDIRECT_ALL_REQUESTS_TO_HTTPS: "true"

  nginx:
    image: nginx:alpine
    ports:
      - "443:443"
    networks:
      - internal
      - external
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      # IP allowlist en amont

networks:
  internal:
    internal: true  # Pas d'acces Internet direct
  external:

Pour les equipes distribuees, deployez un VPN (WireGuard, Tailscale ou OpenVPN) et exigez une connexion VPN pour acceder a Metabase. Les solutions Zero Trust comme Cloudflare Access ou Zscaler permettent d'ajouter une couche d'authentification SSO avant meme que la requete n'atteigne Metabase — un attaquant qui exploite un zero-day Metabase doit d'abord franchir cette barriere d'authentification externe.

— Etape 6 : Activer le monitoring et les alertes temps reel

Les couches de protection precedentes visent a empecher l'exploitation. Le monitoring vise a la detecter quand elle se produit malgre tout — parce qu'un zero-day, par definition, contourne les defenses connues. L'objectif est de detecter les comportements anormaux en temps reel et d'alerter les equipes avant que l'attaquant n'ait le temps d'exfiltrer des donnees significatives.

Indicateurs a surveiller :

# PostgreSQL : activer le logging des requetes
# postgresql.conf
log_statement = 'all'
log_min_duration_statement = 1000  # Log requetes > 1s
log_connections = on
log_disconnections = on

# Alertes sur patterns suspects (exemple avec pg_audit)
# Detecter les requetes UNION SELECT (indicateur d'injection SQL)
# Detecter les requetes sur information_schema ou pg_catalog
# Detecter les exports massifs (COUNT(*) > seuil habituel)
# Detecter les connexions depuis des IP inconnues

Si votre organisation utilise un SIEM (Splunk, Elastic SIEM, Microsoft Sentinel), configurez des alertes specifiques pour les requetes SQL provenant de l'utilisateur Metabase qui contiennent les mots-cles UNION, information_schema, pg_dump, INTO OUTFILE, ou qui retournent un volume de donnees anormalement eleve. Un dashboard de monitoring dedie a l'activite Metabase permet de visualiser les tendances et de detecter les anomalies avant qu'elles ne deviennent des incidents.

— Etape 7 : Mettre en place un plan de reponse a incident

La question n'est pas de savoir si votre Metabase sera cible, mais quand. Un plan de reponse a incident dedie permet de reagir en minutes plutot qu'en jours — et c'est cette difference qui determine si l'incident reste un evenement de securite ou devient une fuite de donnees majeure avec notification CNIL et impact reputationnel.

Checklist de reponse rapide :

# PHASE 1 : Contenir (0-30 minutes)
1. Isoler Metabase du reseau (couper le proxy/VPN)
2. Couper l'acces de l'utilisateur Metabase a la BDD
3. Capturer les logs actuels (Metabase, Nginx, BDD)
4. Notifier le RSSI et l'equipe securite

# PHASE 2 : Analyser (30 min - 4h)
5. Identifier le vecteur d'attaque (logs WAF, requetes BDD)
6. Determiner le perimetre des donnees accessibles/extraites
7. Verifier si d'autres systemes sont compromis
8. Evaluer l'obligation de notification CNIL (72h)

# PHASE 3 : Remedier (4h - 48h)
9. Patcher ou remplacer l'instance Metabase
10. Effectuer la rotation de TOUS les identifiants BDD
11. Renforcer les couches de defense (WAF, reseau)
12. Documenter l'incident et les lecons apprises

Testez ce plan au moins une fois par trimestre avec un exercice de simulation. Un test d'intrusion cible sur Metabase permet de valider l'ensemble de la chaine de defense — du WAF au monitoring en passant par le cloisonnement reseau — et de verifier que le plan de reponse fonctionne dans des conditions realistes.

— Sources et references

Les recommandations de cet article sont basees sur les bulletins de securite de Metabase (CVE-2023-38646, patchs d'aout 2026), les guides de durcissement de l'ANSSI, le Top 10 OWASP 2026 (A03 : Injection), la documentation officielle de Metabase sur la securite, et l'analyse de la fuite DINUM d'aout 2026 exploitant cette meme classe de vulnerabilite.

Conclusion : la securite de Metabase est votre responsabilite

Metabase est un outil puissant qui simplifie l'acces aux donnees. Mais cette simplicite est aussi son talon d'Achille : un outil qui facilite l'acces aux donnees pour vos equipes facilite aussi l'acces aux donnees pour les attaquants quand il n'est pas correctement securise. Les 7 etapes de ce guide ne sont pas des recommandations theoriques — elles sont issues de l'analyse d'incidents reels, dont la fuite DINUM d'aout 2026.

La defense en profondeur est la cle : aucune couche unique ne peut vous proteger contre un zero-day, mais la combinaison d'un WAF, d'une segmentation reseau, de privileges minimaux, d'un monitoring actif et d'un plan de reponse teste permet de contenir l'impact de n'importe quelle vulnerabilite — y compris celles qui n'ont pas encore ete decouvertes. Commencez par l'etape 1 aujourd'hui : verifiez votre version de Metabase et mettez-la a jour.