GeoServer: kaartservices publiceren en veilig houden

GeoServer 3.0.1 is op 11 oktober 2026 de stabiele versie. Op geoserver.org staan drie lijnen naast elkaar: stabiel 3.0.1, onderhoud 2.28.5 en ontwikkeling 3.1 (nightly). De releases 3.0.1, 2.28.5 en 2.27.6 verschenen alle drie op 14 augustus 2026; 3.0.0 volgde op 11 juni 2026. In de aankondiging van 3.0 beschrijft het project de grote verandering: de overstap naar een moderne Java-basis.

The GeoServer ecosystem now runs on JDK 17 and Spring 7

Bron: GeoServer-blog, "GeoServer 3 is here, from crowdfunding to release", 11 juni 2026. De documentatie vermeldt dat GeoServer een Java 17- of Java 21-omgeving vraagt. De homepage toont 2.28 als enige onderhoudslijn; 2.27.6 verscheen in augustus 2026 nog als beveiligingsrelease. Draait u 2.27, plan dan de overstap naar 2.28 of 3.0.

Het project meldt op de eigen site dat het OGC-gecertificeerd is voor WFS, WMS, WCS en WMTS en dat OGC API - Features en WPS als extensie beschikbaar zijn. Wat die standaarden betekenen, staat bij WMS en WMTS en WFS en OGC API Features.

U publiceert met de webinterface of met de REST-API; de REST-API is scriptbaar en daarom hier getest. De stappen zijn: een workspace aanmaken, een GeoPackage als datastore uploaden en daarmee de laag configureren. Het voorbeeld gebruikt het GeoPackage met 32 BAG-panden uit de pagina over GDAL. GeoServer 3.0.1 draaide op Java 21 (macOS), gestart met bin/startup.sh uit de binaire download.

# workspace aanmaken
curl -u admin:geoserver -XPOST -H "Content-Type: application/json" \
  -d '{"workspace":{"name":"demo"}}' http://localhost:8080/geoserver/rest/workspaces

# GeoPackage uploaden en alle lagen configureren
curl -u admin:geoserver -XPUT -H "Content-Type: application/geopackage+sqlite3" \
  --data-binary @bag.gpkg \
  "http://localhost:8080/geoserver/rest/workspaces/demo/datastores/bag/file.gpkg?configure=all"

Beide aanroepen gaven status 201 (aangemaakt). De laag demo:pand had daarna het stelsel EPSG:28992, zoals de BAG-data aanleverde, en GeoServer berekende zelf de omhullende in WGS84. Daarna zijn de services gecontroleerd:

Drie dingen vallen op. De WMTS draait op GeoWebCache, apart van de OWS-services, en biedt standaard alleen EPSG:4326 en EPSG:900913; een RD-raster (EPSG:28992) voegt u zelf toe. De WFS-uitvoer behoudt RD in plaats van WGS84 (het veld crs noemt het). En het lijstveld verblijfsobject.href uit de BAG komt mee als attribuut. Dezelfde URL's laadt u als bron in QGIS.

GeoServer is met verschillende lagen te beveiligen, maar de standaardinstallatie is open voor lezen en heeft een bekend beheerderswachtwoord. In de test gaf de binaire download na het starten het volgende beeld:

• De REST-API gaf zonder inloggegevens status 401 en met het standaardaccount admin met het wachtwoord geoserver status 200. Het standaardwachtwoord werkte dus ongewijzigd.
• Een WMS-GetCapabilities zonder inlog gaf status 200: de services zijn standaard anoniem leesbaar.
• De server luisterde op alle netwerkadapters (0.0.0.0:8080), niet alleen op localhost.

Wijzig daarom bij de eerste start het beheerderswachtwoord, zet de server niet rechtstreeks op internet en plaats er een omgekeerde proxy met TLS voor. De documentatie beschrijft toegangsregels op serviceniveau en op laagniveau. Over de combinatie ervan zegt ze:

Service-level security and Layer security cannot be combined.

Bron: GeoServer-documentatie, Service Security. Dat betekent dat u moet kiezen: bijvoorbeeld een hele WFS-service alleen voor een rol openzetten, of een afzonderlijke laag beperken. Een toegangsregel voor één service of operatie staat in het bestand services.properties in de beveiligingsmap van de data-directory. Een voorbeeld uit de documentatie is dat GetCapabilities anoniem blijft, terwijl schrijfoperaties zoals Transaction beveiligd zijn. Controleer na elke regel uitdrukkelijk met een testgebruiker en zonder inlog wat er toegankelijk is. Voor persoonsgegevens in lagen geldt daarnaast geodata en de AVG.

GeoServer heeft de afgelopen jaren meerdere ernstige kwetsbaarheden gehad, waarvan CVE-2024-36401 de bekendste is. De NVD beschrijft remote code execution zonder inloggen (CVSS 9,8): meerdere OGC-requestparameters laten "Remote Code Execution (RCE) by unauthenticated users" toe. De fix zit in 2.22.6, 2.23.6, 2.24.4 en 2.25.2. De Amerikaanse instantie CISA zette hem op 15 juli 2024 in de lijst Known Exploited Vulnerabilities (misbruik waargenomen), en op 11 december 2025 ook CVE-2025-58360.

Elk nummer is gecontroleerd in de advisorylijst van geoserver/geoserver op GitHub; waar de NVD een andere score geeft, staat die erbij. Over CVE-2026-76904 schrijft het project dat een derde partij het lek publiek maakte vóór de fix, waarna binnen enkele uren scans werden waargenomen. Het advies: werk bij naar 3.0.1, 2.28.5 of 2.27.6.

Voor een beheerder betekent dit: houd elke GeoServer-instantie met versie bij op een lijst, volg de advisories van het project en spreek een maximale updatetermijn af voor kritieke lekken, ook voor test en acceptatie. Over hoe zo'n beheerafspraak met een leverancier eruitziet, staat meer op GIS-beheer en hosting.

De valkuilen hieronder zijn uit de test of uit de documentatie afgeleid.

• De data-directory is de configuratie. Alle workspaces, stores en beveiligingsregels staan in de data-directory. Neem die mee in uw back-up, samen met de databases waar de stores naar verwijzen.
• Beveiliging op twee niveaus. Service- en laagbeveiliging kunnen niet worden gecombineerd (zie het citaat hierboven). Plan het model vooraf.
• Tegelrasters. De WMTS biedt standaard geen RD-raster. Wie voor Nederlandse kaarten tegels wil in EPSG:28992, voegt een eigen raster toe, of gebruikt de PDOK-WMTS; zie PDOK.
• Bronnen van derden. Een kaartlaag die u cachet of herpubliceert, valt onder de voorwaarden van de bron. Lees open data-licenties voor u BAG- of BGT-data in een eigen dienst aanbiedt.
• Het wachtwoord van de beheerder. Zie de test hierboven: het standaardwachtwoord werkte na de eerste start.
• Het versieverschil tussen lijnen. Een overstap van 2.x naar 3.x betekent een nieuw Java-niveau. Test eerst in een kopie.

GeoServer past bij organisaties die veel lagen, stijlen en gebruikers beheren en klassieke OGC-services nodig hebben, en die Java-beheer in huis of bij een leverancier hebben. Minder geschikt is het wanneer u alleen een paar vectorlagen als moderne API wilt aanbieden: dan is pygeoapi eenvoudiger. Heeft u alleen kaartprojecten uit QGIS die u online wilt tonen, dan is QGIS Server een alternatief. En wilt u volledig serverloos werken, dan kan tegelhosting met statische bestanden volstaan, in combinatie met MapLibre.

Weeg ook de beheerlast mee. De CVE-tabel hierboven laat zien dat een publiek bereikbare GeoServer een vast patchritme vraagt, inclusief de extensies die u installeert. Kunt u dat ritme niet borgen, en gaat het om landelijke basisregistraties, dan volstaat het soms om rechtstreeks de services van PDOK te gebruiken en alleen eigen lagen zelf te publiceren.

Verhuist u van een ArcGIS-omgeving en zoekt u het open-sourcealternatief voor kaartservices, dan staat de aanpak op ArcGIS naar open source. Een kant-en-klare omgeving voor gemeenten, met hosting en beheer, beschrijft GIS-viewer voor gemeenten.