Sécurité GeoServer : tenir à jour un serveur exposé

Pourquoi un GeoServer exposé doit être tenu à jour

GeoServer répond par nature à des requêtes venues de l'extérieur : c'est son rôle de servir des cartes et des entités à des clients qu'il ne connaît pas. Chaque requête WMS, WFS ou WPS est analysée par le serveur, et une erreur dans cette analyse peut devenir une porte d'entrée.

Comme tout logiciel de cette taille, GeoServer corrige régulièrement des failles. Le projet publie des versions de maintenance et ne corrige que les branches encore maintenues. Un serveur installé il y a deux ans et jamais mis à jour cumule donc des failles connues, documentées, et parfois exploitées par des robots qui balaient Internet.

La mise à jour ne concerne pas que GeoServer. Le serveur dépend d'un environnement Java, souvent d'un conteneur de servlets, d'extensions qui doivent suivre exactement la même version, et du système d'exploitation de la machine. Une faille dans l'un de ces étages expose tout le reste. Tenir un GeoServer à jour, c'est donc tenir à jour toute la pile qui le porte.

Le cas CVE-2024-36401 : exécution de code à distance

Le 1er juillet 2024, le projet GeoServer a publié l'avis de sécurité GHSA-6jj6-gm7p-fcvv. La bibliothèque GeoTools évaluait les noms de propriétés comme des expressions XPath, ce qui permettait d'exécuter du code arbitraire sur le serveur, sans authentification, par de simples requêtes WFS, WMS ou WPS. Toutes les installations par défaut étaient concernées.

Sources consultées le 09/11/2026 : avis GHSA-6jj6-gm7p-fcvv sur le dépôt GitHub de GeoServer, et alerte de la CISA du 15 juillet 2024 sur cisa.gov annonçant l'ajout au catalogue KEV.

Cet avis illustre la façon de lire n'importe quel bulletin de sécurité GeoServer. Repérez d'abord les versions touchées et comparez-les à la vôtre. Lisez ensuite les versions corrigées : si votre branche n'en a pas, la seule issue est de changer de branche. Le score de gravité fixe l'urgence : au-dessus de 9, on agit le jour même. La rubrique de contournement dit quoi faire en attendant la mise à jour, et à quel prix fonctionnel. Enfin, l'inscription dans un catalogue de failles exploitées signifie que des attaques ont déjà lieu : la question n'est plus de savoir si un serveur exposé sera visé, mais quand.

Ce que cette faille enseigne

• Un service public est une surface d'attaque. La faille ne demandait aucun mot de passe : protéger la console d'administration ne suffisait pas.
• Le délai compte. Entre la publication de l'avis et les premières exploitations observées, il s'est écoulé environ une semaine. Une mise à jour trimestrielle ne protège pas d'une faille de ce type.
• Les vieilles branches restent vulnérables. Seules les branches maintenues ont reçu un correctif ; une installation trop ancienne obligeait à changer de version, pas seulement à appliquer un patch.
• Il faut savoir ce qui tourne. Beaucoup d'organisations ont découvert à cette occasion un GeoServer oublié, installé pour un projet passé.

Sécurité GeoServer : les bonnes pratiques

• Changer le mot de passe administrateur par défaut dès l'installation, et créer des comptes nominatifs plutôt que de partager le compte admin.
• Ne pas exposer la console d'administration à tout Internet : la réserver à un réseau interne, un VPN ou une liste d'adresses autorisées.
• Rester sur une version maintenue et suivre les avis de sécurité du projet sur geoserver.org et son dépôt GitHub.
• N'activer que les services utiles. Si WPS ou WCS ne servent pas, désactivez-les : moins de services, moins de surface.
• Régler les droits par espace de travail et par couche, en particulier l'écriture WFS-T.
• Placer GeoServer derrière un proxy inverse en HTTPS, et journaliser les requêtes pour repérer les comportements anormaux.
• Utiliser des comptes de base de données en lecture seule pour les entrepôts PostGIS qui n'ont pas besoin d'écrire.

Le premier point n'est pas théorique : la documentation de GeoServer indique que la console s'ouvre par défaut avec l'utilisateur admin et le mot de passe geoserver. Ces identifiants sont connus de tous, y compris des robots qui testent les serveurs exposés. Un GeoServer en ligne qui les accepte encore doit être considéré comme ouvert.

Comptes, rôles et règles d'accès

GeoServer gère ses propres utilisateurs, groupes et rôles, et applique deux familles de règles. Les règles de couches décident qui peut lire, écrire ou administrer chaque espace de travail et chaque couche. Les règles de services décident qui peut appeler une opération donnée, par exemple l'écriture WFS. Selon la documentation du projet, la configuration par défaut laisse tout utilisateur anonyme lire toutes les couches et réserve l'écriture aux administrateurs : c'est raisonnable pour des données publiques, beaucoup moins pour un espace qui mêle données ouvertes et données internes.

# Couches : espace.couche.mode=rôles (r lecture, w écriture, a administration)
*.*.r=*
*.*.w=ROLE_ADMINISTRATOR
cadastre.*.r=ROLE_AGENTS

# Services : service.opération=rôles
wfs.Transaction=ROLE_EDITEURS

• Un rôle par usage, pas par personne : lecteurs internes, éditeurs, administrateurs. On ajoute ou retire ensuite des utilisateurs sans toucher aux règles.
• Séparer les données par espace de travail : un espace public, un espace interne. Les règles s'écrivent alors en une ligne par espace au lieu d'une ligne par couche.
• Réserver l'écriture WFS-T à un rôle précis, même si l'entrepôt PostGIS sous-jacent n'autorise déjà que certaines tables en écriture : deux verrous valent mieux qu'un.
• Ne pas mélanger les deux familles pour un même besoin : la documentation précise qu'une règle de service ne peut pas viser une couche particulière. Pour protéger une couche, c'est une règle de couche qu'il faut.
• Tester avec un compte non administrateur. Un administrateur voit tout ; seul un compte ordinaire, ou une session anonyme, montre ce que le public obtient réellement.

N'oubliez pas l'API REST, qui permet de tout configurer par programme : la documentation recommande de la verrouiller par une règle générale qui réserve toutes ses méthodes au rôle administrateur. Un script d'automatisation doit alors utiliser un compte dédié, avec un mot de passe distinct de celui des personnes.

Régler GeoServer pour la production

Une installation sortie du paquet est réglée pour découvrir le logiciel, pas pour être exposée. La documentation de GeoServer consacre une partie entière au passage en production ; voici les réglages qui touchent directement la sécurité.

• Journalisation : choisir le profil de production, plus sobre, et conserver les journaux assez longtemps pour remonter le fil d'un incident.
• Exceptions détaillées : l'option qui ajoute la pile d'appels Java aux messages d'erreur sert au débogage ; la documentation la réserve aux tests. En production, elle renseigne inutilement un attaquant sur l'intérieur du serveur.
• Services globaux : désactivés, ils obligent les clients à passer par les services propres à chaque espace de travail, ce qui cloisonne mieux les données.
• Services inutiles : un service peut être coupé depuis la console, ou par une propriété système qui en liste plusieurs à la fois. Un WPS ou un WCS que personne n'appelle ne doit pas répondre.
• Console d'administration : quand l'administration passe par l'API REST ou par des fichiers déployés, la console web peut être entièrement désactivée par une propriété Java au démarrage. Sinon, elle reste joignable mais filtrée par le proxy inverse.

Notez chaque réglage dans un document d'exploitation, avec sa raison. Lors de la prochaine mise à jour ou du prochain changement d'administrateur, c'est ce document qui évite de revenir, par inadvertance, à une configuration de démonstration.

Une routine de mise à jour réaliste

1. S'abonner aux annonces de sécurité de GeoServer et noter la branche maintenue la plus récente.
2. Sauvegarder le répertoire de données (configuration, styles, couches) avant toute mise à jour.
3. Tester la nouvelle version sur une copie : couches, styles SLD, extensions installées.
4. Appliquer en production, puis vérifier les GetCapabilities et quelques couches clés dans QGIS.
5. En cas de faille critique, ne pas attendre la fenêtre habituelle : appliquer le correctif ou le contournement publié le jour même.

Cette routine prend du temps, surtout quand des extensions doivent suivre la même version. C'est l'un des coûts cachés de l'auto-hébergement détaillés dans notre guide sur le coût d'un SIG web open source.

Pour que l'étape de test tienne en une journée, préparez une liste de contrôle fixe : lecture du GetCapabilities de chaque service, affichage de trois ou quatre couches représentatives en WMS, une requête WFS sur une grosse table, une édition WFS-T si vous en proposez, une connexion avec un compte non administrateur, puis lecture des journaux à la recherche d'erreurs au démarrage. Si tout passe sur la copie, la mise en production n'est plus un saut dans l'inconnu.

Inventorier, surveiller et réagir

La sécurité GeoServer commence par une question simple : combien de GeoServer votre organisation fait-elle tourner, et dans quelles versions ? Beaucoup d'équipes découvrent, lors d'une alerte, un serveur de test resté en ligne ou une installation montée par un prestataire puis oubliée. Une liste à jour vaut mieux que la meilleure configuration appliquée à moitié des serveurs.

• Recenser chaque GeoServer : adresse, version, branche, extensions installées, responsable, date de la dernière mise à jour.
• Vérifier l'exposition depuis l'extérieur : depuis un réseau tiers, la console d'administration ne doit pas répondre, alors que les services publics, eux, répondent.
• Surveiller les journaux : des requêtes en rafale, des paramètres inhabituels dans les filtres ou des appels WPS que personne n'utilise sont des signaux d'alerte.
• Préparer un plan de réaction : qui décide d'arrêter un service, comment le couper rapidement, où se trouve la dernière sauvegarde du répertoire de données.
• Appliquer les contournements publiés quand la mise à jour ne peut pas attendre. Pour CVE-2024-36401, l'avis du projet proposait de retirer un composant de GeoTools (gt-complex) en attendant la mise à jour, au prix de certaines fonctions avancées, ou de remplacer des fichiers corrigés pour les versions plus anciennes.

Un contournement reste provisoire : il réduit le risque le temps de planifier la vraie mise à jour, il ne la remplace pas. Enfin, en cas de doute sur une compromission, une simple mise à jour ne suffit pas : il faut vérifier que rien n'a été déposé sur le serveur entre-temps, et repartir si besoin d'une installation propre avec un répertoire de données restauré.

Les erreurs de sécurité les plus fréquentes

La plupart de ces erreurs ne viennent pas d'un manque de compétence, mais d'un manque de temps : un serveur installé pour un projet, puis laissé de côté une fois le projet livré. C'est pourquoi la sécurité GeoServer se joue surtout sur l'organisation : un responsable nommé, une liste à jour et une routine tenue, plus que sur un réglage isolé.

Déléguer la sécurité sans renoncer à GeoServer

Avec GeoServer Cloud, GeoServer est installé, sécurisé, mis à jour et surveillé par LizPack. Vous travaillez dans un espace isolé, avec la console GeoServer habituelle, sans gérer ni Java ni serveur. Les couches des autres comptes ne sont ni visibles ni accessibles.

Si vos données doivent rester chez vous, LizPack Entreprise installe GeoServer sur votre infrastructure, piloté depuis un portail. Pour comparer les options d'hébergement, voyez l'hébergement GeoServer en ligne, et pour situer GeoServer face aux autres serveurs, notre comparatif.

Questions fréquentes