Skip to main content

Securing Nexus Repository

Below are suggestions for making your Nexus Repository instance more secure.

Limit IPs that can be reached from your Nexus Repository Host

Nexus Repository can be configured by an administrator to contact internal and external IPs for various reasons such as retrieving certificates, creating proxy repositories, dispatching events to remote URLs, and so on. You may limit the IPs that can be reached from the host machine running your Nexus Repository instance but note that doing so could block the main use case for some features.

For example, webhooks give administrators a way of integrating Nexus Repository with other systems (e.g. an auditing system, another Nexus Repository instance, or a lightweight listener potentially on the same host), typically in the same data center. Hence, limiting webhook destinations to, for example, IPs external to your data center effectively blocks the main use case for them.

Privileges and Service Account

  • Only assign the least necessary privileges to Nexus Repository users.

  • Create a dedicated operating system service account for running Nexus Repository - do not run as the root user. In addition, the service account must have read/write permissions to the $install-dir and sonatype-work directories and must be able to create a valid shell. See our System Requirements for detailed operating system service account recommendations.

Containerization

Running Nexus Repository in a Docker container may reduce the impact of a successful attack. Without containerisation, if a malicious person successfully exploits a service and gains root access, they could do damage to other services running on the host. On the other hand, containerising means a successful attack on that service is restricted to the container running that service.

The Nexus Repository 3 docker images are found at: https://hub.docker.com/r/sonatype/nexus3/.

URL Validation and Private Network Access

Sonatype Nexus Repository allows URL validation to reduce the risk of Server-Side Request Forgery (SSRF) when configuring outbound connections. This validation applies to proxy repository Remote Storage URLs and Amazon S3 blob store Endpoint URL values. When you save a configuration, Nexus Repository checks whether the specified URL resolves to a private network address, a localhost or loopback address, or a cloud instance metadata address. If validation is enabled and the URL resolves to a blocked address, the configuration cannot be saved.

In Nexus Repository, private network URL validation behavior depends on the installation type:

  • New installations (no existing content) have SSRF protection enabled by default.

  • Existing installations (with content) have SSRF protection disabled by default and must be enabled explicitly.

Note

SSRF protection behavior differs by installation type:

Self-hosted: SSRF protection defaults to disabled for existing installations (enabled for new installations). Administrators can manage settings via the REST API.

Cloud: SSRF protection is enabled by default and managed by Sonatype. The /v1/security/ssrf-protection API endpoints are not available in cloud deployments.

You can explicitly control this behavior using configuration properties, either by allowing private networks or by restricting access while allowing specific IP addresses or domains. SSRF protection can be configured using an administrator REST API. Properties in nexus.properties or environment variables are used only for initial configuration, which is useful for containerized, Docker, or Kubernetes-based deployments.

API-based configuration

Administrators can manage SSRF protection using the following endpoints:

  • GET /v1/security/ssrf-protection – retrieve current configuration

  • PUT /v1/security/ssrf-protection – update configuration

Changes made via the API:

  • Take effect immediately without restart

  • Are persisted in the database

  • Override any values previously set in nexus.properties

To allow/disallow proxying to private networks, add the following configuration:

nexus.proxy.allowPrivateNetworks=true|false        #default: true

To block private networks while allowing specific IP addresses, configure:

nexus.proxy.allowPrivateNetworks=false
nexus.proxy.privateNetworks.allowedIPs=192.x.x.x,192.168.x.x

Note that the IP addresses are separated by a comma. IP ranges are not supported.

To block private networks while allowing specific domains, configure:

nexus.proxy.allowPrivateNetworks=false
nexus.proxy.privateNetworks.allowedDomains=myinternaldomain.com,anotherinternaldomain.com

Note

Domain names are separated by commas and must resolve to internal IPs. Wildcards, domain suffix matching, and recursive subdomain matching are not supported.

You can also configure these properties using environment variables, which is useful for Dockerized or Kubernetes-based deployments.

Property: nexus.proxy.allowPrivateNetworks
Environment Variable: NEXUS_PROXY_ALLOWPRIVATENETWORKS
Example: NEXUS_PROXY_ALLOWPRIVATENETWORKS=false

Property: nexus.proxy.privateNetworks.allowedIPs
Environment Variable: NEXUS_PROXY_PRIVATENETWORKS_ALLOWEDIPS
Example: NEXUS_PROXY_PRIVATENETWORKS_ALLOWEDIPS=192.x.x.x,10.x.x.x

Property: nexus.proxy.privateNetworks.allowedDomains
Environment Variable: NEXUS_PROXY_PRIVATENETWORKS_ALLOWEDDOMAINS
Example: NEXUS_PROXY_PRIVATENETWORKS_ALLOWEDDOMAINS=internal.company.com,myapp.local

These properties are applied only during initial startup.

After SSRF protection settings are modified via the API, the database-stored configuration is used and property values are no longer applied.

If your proxy repositories require access to internal or private network resources, ensure those IPs or domains are added to the allowlist before enabling SSRF protection.

Important

SSRF protection is enabled by default only for new installations. Existing installations are not changed automatically to avoid disrupting existing configurations. Customers are encouraged to review their configurations for any internal IP addresses or private network ranges and update them as needed to prevent service disruptions.