Configuration Considerations¶

Use production logging¶

Excessive logging may visibly affect the performance of your server. High logging levels are often necessary to track down issues, but during operation you should run with low levels. (You can switch the logging levels while GeoServer is running.)

You can change the logging level in the Logging Profile. You will want to choose the PRODUCTION logging configuration, where only problems are written to the log files.

Personalize your server¶

In order to your GeoServer as welcoming as possible, you should customize the server’s metadata to your organization. It may be tempting to skip some of the configuration steps, and leave in the same keywords and abstract as the defaults, but this will only confuse potential users.

Suggestions:

• Fill out Service Metadata sections for WFS, WMS, WCS, WMTS web services.

• Use Contact Information to provide service welcome message, contact details and a link to your organisation.

  This message is be shown to visitors at the top of welcome page. The contact details and organisation information are included in the welcome page, and used to describe each web service in the capabilities documents.

• When setting up a workspace you can provide more detailed service metadata and contact information.

• Serve your data with your own namespace (and provide a correct URI)

• Remove default layers (such as topp:states)

Configure service limits¶

Make sure clients cannot request an inordinate amount of resources from your server.

In particular:

• Set the maximum amount of features returned by each WFS GetFeature request (this can also be set on a per featuretype basis by modifying the layer publishing wfs settings).

• Set the WMS request limits so that no request will consume too much memory or too much time.

• Set WPS limits, so no process will consume too much memory or too much time. You may also limit the size input parameters for further control.

• Install and configure the Control flow module for greater control of client access.

Welcome page selectors¶

The workspace and layer selectors might take a lot of time to fill up against large catalogs. Because of this, GeoServer tries to limit the time taken to fill them (by default, 5 seconds), and the number of items in them (by default, 1000), and will fall back on simple text fields if the time limit is reached.

In some situations, that won’t be enough and the page might get stuck anyways. The following properties can be used to tweak the behavior:

• GeoServerHomePage.selectionMode : can be set to text to always use simple text fields, dropdown to always use dropdowns, or auto to use the default automatic behavior.

• GeoServerHomePage.selectionTimeout : the time limit in milliseconds, defaults to 5000.

• GeoServerHomePage.selectionMaxItems : the maximum number of items to show in the dropdowns, defaults to 1000.

When using text selection mode the page description is static, no longer offering of available workspace and layers.

Cache your data¶

Server-side caching of WMS tiles is the best way to increase performance. In caching, pre-rendered tiles will be saved, eliminating the need for redundant WMS calls. There are several ways to set up WMS caching for GeoServer. GeoWebCache is the simplest method, as it comes bundled with GeoServer. (See the section on GeoWebCache for more details.) Another option is TileCache.

You can also use a more generic non-spatial caching system, such as Ehcache (an embedded cache service) or Squid (a web cache proxy).

Caching is also possible for WFS layers, in a very limited fashion. For DataStores that don’t have a quick way to determine feature counts (e.g. shapefiles), enabling caching can prevent querying a store twice during a single request. To enable caching, set the Java system property org.geoserver.wfs.getfeature.cachelimit to a positive integer. Any data sets that are smaller than the cache limit will be cached for the duration of a request, which will prevent the dataset from being queried a second time for the feature count. Note that this may adversely affect some types of DataStores, as it bypasses any feature count optimizations that may exist.

Set security for data modification¶

GeoServer includes support for WFS-T (transactions) which lets users modify your data.

If you don’t want your database modified, you can turn off transactions in the WFS settings. Set the Service Level to Basic. For extra security, we recommend any database access use datastore credentials providing read-only permissions. This will eliminate the possibility of a SQL injection (though GeoServer is generally not vulnerable to that sort of attack).

If you would like some users to be able to modify data, set the service level Service Level to Transactional (or Complete) and use Service Security to limit access to the WFS.Transaction operation.

If you would like some users to be able to modify some but not all of your data, set the Service Level to Transactional (or Complete), and use Layer security to limit write access to specific layers. Data security can be used to allow write access based on workspace, datastore, or layer security.

Logging configuration hardening¶

For production systems, it is advised to set GEOSERVER_LOG_LOCATION parameter during startup. The value may be defined as either an environment variable, java system property, or servlet context parameter.

The location set for GEOSERVER_LOG_LOCATION has priority, causing the setting provided using the Admin Console or REST API to be ignored.

See Overriding the log location setup in the GeoServer configuration for more information.

Disable the GeoServer web administration interface¶

In some circumstances, you might want to completely disable the web administration interface. There are two ways of doing this:

• Set the Java system property GEOSERVER_CONSOLE_DISABLED to true by adding -DGEOSERVER_CONSOLE_DISABLED=true to your container’s JVM options

• Remove all of the gs-web*-.jar files from WEB-INF/lib

Showing Environment Variables and Java System Properties¶

Module status information is available describing the operational environment.

• The GeoServer Status page Module Status.

• The REST /geoserver/rest/about/status endpoint lists module status information

1. By default GeoServer does not show Environment Variables and Java System Properties.

2. To show environment variables and Java system properties on the status page and REST API, start GeoServer with these environment variables set to true:

   • GEOSERVER_MODULE_SYSTEM_ENVIRONMENT_STATUS_ENABLED

   • GEOSERVER_MODULE_SYSTEM_PROPERTY_STATUS_ENABLED

3. In a production system, these should be set to false (or leave them undefined).

   Warning

   While this feature can help an administrator debug a GeoServer instance’s configuration, environment variables can include sensitive information such as database passwords and API access keys/tokens, particularly when running in a containerised environment (such as Docker or Kubernetes) or with ALLOW_ENV_PARAMETRIZATION=true.

   Note

   Linux

   Linux administrators can get a list of all environment variables set at GeoServer startup with:

   tr '\0' '\n' < /proc/${GEOSERVER_PID}/environ
   

Set a service strategy¶

A service strategy is the method in which output is served to the client. This is a balance between proper form (being absolutely sure of reporting errors with the proper OGC codes, etc.) and speed (serving output as quickly as possible). This is a decision to be made based on the function that GeoServer is providing.

In Apache Tomcat you can provide system property by creating conf/Catalina/localhost/geoserver.xml:

<Context>
  <Parameter name="serviceStrategy"
             value="PARTIAL-BUFFER2" override="false"/>
</Context>

You can configure the default service strategy by modifying the web.xml file of your GeoServer instance:

<context-param>
    <param-name>serviceStrategy</param-name>
    <param-value>PARTIAL-BUFFER2</param-value>
</context-param>

The possible strategies are:

Disable the Auto-complete on web administration interface login¶

To disable the Auto Complete on Web Admin login form:

• Set the Java system property geoserver.login.autocomplete to off by adding -Dgeoserver.login.autocomplete=off to your container’s JVM options

• If the browser has already cached the credentials, please consider clearing the cache or form data after setting the JVM option.

Disable anonymous access to the layer preview page¶

In some circumstances, you might want to provide access to the layer preview page to authenticated users only. The solution is based on adding a new filter chain with a rule matching the path of the layer preview page to GeoServer’s Authentication chain. Here are the steps to reproduce:

• Under Security -> Authentication -> Filter Chains, add a new HTML chain

• Set the new chain’s name to webLayerPreview (or likewise)

• As Ant pattern, enter the path of the layer preview page, which is /web/wicket/bookmarkable/org.geoserver.web.demo.MapPreviewPage (since it’s an Ant pattern, the path could as well be written shorter with wildcards: /web/**/org.geoserver.web.demo.MapPreviewPage)

• Check option Allow creation of an HTTP session for storing the authentication token

• Under Chain filters, add filters rememberme and form (in that order) to the Selected list on the right side

• Close the dialog by clicking the Close button; the new HTML chain has been added to the list of chains as the last entry

• Since all chains are processed in turn from top to bottom, in order to have any effect, the new webLayerPreview chain must be positioned before the web chain (which matches paths /web/**,/gwc/rest/web/**,/)

• Use the Position arrows on the left side of the list to move the newly added chain upwards accordingly

• Save the changes you’ve made by clicking the Save button at the bottom of the page

With that in place, unauthenticated users now just get forwarded to the login page when they click the layer preview menu item link.

The above procedure could as well be applied to other pages of the web administration interface that one needs to remove anonymous access for. For example:

• Demos -> Demo requests (path: /web/wicket/bookmarkable/org.geoserver.web.demo.DemoRequestsPage)

• Demos -> WCS request builder (path: /web/wicket/bookmarkable/org.geoserver.wcs.web.demo.WCSRequestBuilder)

X-Frame-Options Policy¶

In order to prevent clickjacking attacks GeoServer defaults to setting the X-Frame-Options HTTP header to SAMEORIGIN. This prevents GeoServer from being embedded into an iFrame, which prevents certain kinds of security vulnerabilities. See the OWASP Clickjacking entry for details.

If you wish to change this behavior you can do so through the following properties:

• geoserver.xframe.shouldSetPolicy: controls whether the X-Frame-Options header should be set at all. Default is true.

• geoserver.xframe.policy: controls what to set the X-Frame-Options header to. Default is SAMEORIGIN. Valid options are DENY, SAMEORIGIN and ALLOW-FROM [uri].

These properties can be set either via Java system property, command line argument (-D), environment variable or web.xml init parameter.

If the geoserver.csp.frameAncestors system property has not been set, the frame-ancestors directive of the Content-Security-Policy header will default to being set based on the value of the X-Frame-Options header.

• SAMEORIGIN will be frame-ancestors 'self'

• DENY will be frame-ancestors 'none'

• if the X-Frame-Options header is not set or has any other value, the frame-ancestors directive will be omitted

When both frame-ancestors and X-Frame-Options are present, browsers that support frame-ancestors should enforce the frame-ancestors policy and ignore the X-Frame-Options policy.

X-Content-Type-Options Policy¶

In order to mitigate MIME confusion attacks (which often results in Cross-Site Scripting), GeoServer defaults to setting the X-Content-Type-Options: nosniff HTTP header. See the OWASP X-Content-Type-Options entry for details.

If you wish to change this behavior you can do so through the following property:

• geoserver.xContentType.shouldSetPolicy: controls whether the X-Content-Type-Options header should be set. Default is true.

This property can be set either via Java system property, command line argument (-D), environment variable or web.xml init parameter.

X-XSS-Protection Policy¶

GeoServer supports setting the X-XSS-Protection HTTP header in order to control the built-in reflected XSS filtering that existed in some older browsers. This header is NOT enabled by default since it does not affect modern browsers. Enabling the header without specifying a policy will default to Spring Security’s default of 0 (which is also the current OWASP recommendation). See the OWASP X-XSS-Protection entry for details.

If you wish to change this behavior you can do so through the following properties:

• geoserver.xXssProtection.shouldSetPolicy: controls whether the X-XSS-Protection header should be set at all. Default is false.

• geoserver.xXssProtection.policy: controls what to set the X-XSS-Protection header to. Default is 0. Valid options are 0, 1 and 1; mode=block.

These properties can be set either via Java system property, command line argument (-D), environment variable or web.xml init parameter.

Strict-Transport-Security Policy¶

In order to reduce the possibility of man-in-the-middle attacks GeoServer supports setting the Strict-Transport-Security HTTP header. This header is NOT enabled by default and, when enabled, this header will only be set on HTTPS requests. If a policy has not been set, the default policy will be the same as Spring Security’s default of max-age=31536000 ; includeSubDomains. See the OWASP Strict-Transport-Security entry for details.

If you wish to change this behavior you can do so through the following properties:

• geoserver.hsts.shouldSetPolicy: controls whether the Strict-Transport-Security header should be set at all. Default is false.

• geoserver.hsts.policy: controls what to set the Strict-Transport-Security header to. Default is max-age=31536000 ; includeSubDomains. Valid options can change the max-age to the desired age in seconds and can omit the includeSubDomains directive.

These properties can be set either via Java system property, command line argument (-D), environment variable or web.xml init parameter.

Content-Security-Policy¶

In order to mitigate cross-site scripting and clickjacking attacks GeoServer defaults to setting the Content-Security-Policy HTTP header based on rules configured by the administrator. See the Content Security Policy page for more details about this header, GeoServer’s default configuration and how to change the configuration.

OWS ServiceException XML mimeType¶

By default, OWS Service Exception XML responses have content-type set to application/xml.

In case you want it set to text/xml instead, you need to setup the Java System properties:

• -Dows10.exception.xml.responsetype=text/xml for OWS 1.0.0 version

• -Dows11.exception.xml.responsetype=text/xml for OWS 1.1.0 version

FreeMarker Template Auto-escaping¶

By default, FreeMarker’s built-in automatic escaping functionality will be enabled to mitigate potential cross-site scripting (XSS) vulnerabilities in cases where GeoServer uses FreeMarker templates to generate HTML output and administrators are able to modify the templates and/or users have significant control over the output through service requests. When the GEOSERVER_FORCE_FREEMARKER_ESCAPING property is set to false, auto-escaping will delegate either to the feature’s default behavior or other settings which allow administrators to enable/disable auto-escaping on a global or per virtual service basis. This property can be set to false either via Java system property, command line argument (-D), environment variable or web.xml init parameter.

This setting currently applies to the WMS GetFeatureInfo HTML output format and may be applied to other applicable GeoServer functionality in the future.

External Entities Resolution¶

When processing XML documents from service requests (POST requests, and GET requests with FILTER and SLD_BODY parameters) XML entity resolution is used to obtain any referenced documents. This is most commonly seen when the XML request provides the location of an XSD schema location for validation).

GeoServer provides a number of facilities to control external entity resolution:

• By default http and https entity resolution is restricted to the following default:

  www.w3.org|schemas.opengis.net|www.opengis.net|inspire.ec.europa.eu/schemas
  

  The default list includes the common w3c, ogc, and inspire schema locations required for OGC Web Service operation.

  Access is provided to the proxy base url from global settings. Access to local file references is restricted.

• To allow additional external entity http and https locations use a comma or bar separated list:

  -DENTITY_RESOLUTION_ALLOWLIST=server1|server2|server3/schemas
  

  These locations are in addition to the default w3c, ogc, and inspire schema locations above. Access is provided to the proxy base url from global settings. Access to local file references remains restricted.

• To allow all http and https entity resolution use * wildcard:

  -DENTITY_RESOLUTION_ALLOWLIST=*
  

  Access to local file references remains restricted.

• To turn off all restrictions (allowing http, https, and file references) use the global setting Unrestricted XML External Entity Resolution.

  This setting prevents ENTITY_RESOLUTION_ALLOWLIST from being used.

Spring Security Firewall¶

GeoServer defaults to using Spring Security’s StrictHttpFirewall to help improve protection against potentially malicious requests. However, some users will need to disable the StrictHttpFirewall if the names of GeoServer resources (workspaces, layers, styles, etc.) in URL paths need to contain encoded percent, encoded period or decoded or encoded semicolon characters. The GEOSERVER_USE_STRICT_FIREWALL property can be set to false either via Java system property, command line argument (-D), environment variable or web.xml init parameter to use the more lenient DefaultHttpFirewall.

Static Web Files¶

GeoServer by default allows administrators to serve static files by simply placing them in the www` subdirectory of the GeoServer data directory. If this feature is not being used to serve HTML/JavaScript files or is not being used at all, the GEOSERVER_DISABLE_STATIC_WEB_FILES property can be set to true to mitigate potential stored XSS issues with that directory. See the Serving Static Files page for more details.