GeoServer security: layer permissions, authentication and proxy configuration
Configure GeoServer access across roles, REST, proxy and caches, then test anonymous reads, private attributes and administrative endpoints.
Editorial review: 2026-09-23
A production GeoServer needs separate answers to four questions: who can reach it, who is the user, what may that user read or change, and how much work may one request consume? TLS answers only the transport question. A login page answers neither layer authorization nor cache isolation.
This guide designs a public map service with private administration and read-only database access. It is an operational procedure, not a universal copy-and-paste security configuration. Use the synthetic lab to rehearse; adapt identity, networks and limits to your installation. Follow the security documentation matching your installed release, especially when extensions change authentication behavior.
1. Draw the actual request paths
Write down the external hostname, reverse proxy, GeoServer port, data sources and administrative route. Include GeoWebCache, REST configuration, monitoring and any direct internal URLs. A protected public hostname is ineffective if the same server remains reachable through its unprotected port.
Public readers -> HTTPS edge -> allowed read services -> GeoServer -> read-only DB role
Administrators -> private access -> administration / REST -> controlled configuration
Editors -> separate authorized write workflow -> explicit validation and database role
The public service and administrative service can share an installation, but their exposure and permissions must be independently deliberate. Database network access should be restricted to the required application hosts. Do not expose a database just to make a troubleshooting command convenient.
2. Publish a safe data product
Choose the fields and rows that are actually public. For example, a parcel visualization may need an identifier, geometry and review category but no owner name or contact information. Publish a database view or dedicated table containing only approved fields. That provides a useful second boundary if an application query changes.
Review every access path: WMS image, GetFeatureInfo, WFS feature download, metadata, layer preview and cached tiles. Hiding a field in the web viewer does not prevent a direct feature request from returning it. Likewise, making a layer non-advertised is a discovery choice, not a permission rule; the GeoServer layer documentation distinguishes these behaviors.
Give GeoServer a role with only the database privileges it needs. A read-only public endpoint should not connect as the owner of all cadastral tables. If you retain WFS-T for a different workflow, give that workflow a separate account and test edit authorization and validation explicitly.
3. Understand authentication and authorization
Authentication establishes identity. Authorization determines permitted operations and resources. GeoServer's authentication chain selects filters according to request matching; configuration order matters. A browser session working in the admin interface does not prove that an API client, WMS request or REST request follows the intended chain.
Define concrete identities for testing: anonymous public reader, authenticated restricted reader, editor and administrator. Use a deliberately inaccessible layer alongside a public one. Test the exact service operations each identity should and should not perform. If the installation uses an external identity provider, test expired credentials, removed group membership and logout/refresh behavior through the real proxy path.
GeoServer's built-in layer security has constraints on combining layer and service rules. Do not assume a permission matrix can be expressed by stacking any two rule sets. Choose the supported mechanism for your actual granularity; more complex policies may require a reviewed extension or an application boundary. Record that dependency in the upgrade plan.
4. Restrict configuration separately
REST endpoints configure stores, layers and styles; they are not merely another feature download interface. Restrict them to administrators and approved automation. Also restrict the web administration interface and remove demo data that should not be public. Rotate installation defaults before exposing the service.
Use GeoServer's REST security reference for the deployed release. At the network/proxy layer, allow only the intended public paths and methods. An allowlist is easier to inspect than a growing set of guesses about every possible administrative path. Keep a private recovery path so a mistaken identity configuration does not force unsafe public access to repair it.
Automation accounts should have a distinct owner and purpose. Do not reuse the administrator's browser credentials in CI. Store secrets in the deployment system, keep them out of command arguments where practical, and redact authentication headers and connection strings from diagnostics.
5. Configure the reverse proxy as part of the contract
The external URL must generate correct HTTPS links in capabilities and redirects. Test the advertised URLs from outside the internal network; a successful local request can still advertise localhost or an inaccessible private host. Set GeoServer's proxy base URL and forwarded-header handling according to a known proxy topology.
Trust forwarded identity and host headers only from your own proxy. Strip client-supplied values at the edge before adding trusted ones. Do not solve a redirect problem by indiscriminately trusting every forwarded header. Confirm upload/body-size limits, request timeout, connection limits and allowed methods for each public operation.
CORS controls whether browser code can read cross-origin responses; it is not access control for direct HTTP clients. Enable only origins needed by the application when appropriate, and test the browser's preflight behavior for authorized APIs. Public open data may intentionally allow broad cross-origin reads, but that decision should follow the data license and publication scope.
6. Bound expensive operations
Choose limits from measured workloads: maximum feature count, image dimensions/rendering budget, concurrent requests and database statement duration. An upper bound should protect service availability while allowing the intended task. A limit so low that clients silently truncate results can create data-quality failures, so make truncation visible and provide a documented bulk-download alternative when needed.
Use a workload table rather than one arbitrary global timeout:
| Operation | Expected use | Candidate control | Failure proof |
|---|---|---|---|
| Map image | Interactive viewport | Image/render bounds | Oversized request rejected or bounded |
| Feature page | Small filtered result | Count and query limits | Large count cannot bypass server maximum |
| Bulk export | Explicit approved job | Separate path and quota | Interactive endpoint stays responsive |
| Style/config update | Admin automation | Private route and role | Public credentials cannot write |
| Tile fetch | Repeated published maps | Cache and connection controls | Private tiles cannot cross identities |
Do not expose unneeded processing extensions or dynamic styling capabilities simply because they are installed. Each public capability adds a behavior that must be maintained and tested.
7. Run negative tests through the public edge
Use the real hostname and the same route consumers will use. A local-only security test misses proxy and cache mistakes. Keep test data synthetic and avoid copying tokens into an issue or screenshot.
| Identity/request | Expected result |
|---|---|
| Anonymous reader, public WMS | Intended map only |
| Anonymous reader, restricted WFS | No protected feature payload |
| Reader, configuration write | Rejected; configuration unchanged |
| Revoked group member | Restricted data no longer accessible |
| Request with forged identity header | Header ignored or overwritten |
| Direct application port from outside | Not reachable |
| Repeated private tile under another user | No cross-user result reuse |
| Error from failed database connection | Useful status without secrets |
Read back state after failed writes: an error response is not enough if a partial change occurred. Test both GET and POST forms of supported OGC requests where applicable. Verify that capabilities do not unintentionally reveal restricted names if your policy requires hiding them.
8. Keep the system secure after launch
Maintain a version and extension inventory, monitor the project's security announcements, and practice upgrades in a restored environment. Patch planning must include Java/runtime compatibility, extensions, authentication and representative consumers. Restrict logs to useful operational fields; tokens, private attributes and full sensitive query strings do not belong in routine logs.
Connect alerts to actions: increasing failures trigger service diagnosis; repeated slow queries trigger workload review; failed backups trigger recovery investigation. Keep one named operator responsible for the next step. A dashboard with no operational owner is not incident response.
Continue with the GeoServer recovery and upgrade procedure. If identity, row-level scope or edit workflows are complex, include those requirements in the migration assessment before choosing a replacement architecture.