Recommended security configuration for Assets Server

This document lists the recommended secure configuration for Assets Server.

Note: Depending on your deployment architecture and integration requirements, some values may need to be adjusted. All properties listed here are configured in the cluster-config.properties.txt file. Properties where the default value already aligns with best practice are not listed.

1. Transport security (HTTPS / TLS)

All communication between clients and Assets Server should be encrypted.

Setting up the keystore

Assets Server uses a Java keystore (JKS) to store its TLS certificate and private key. Create it in the configuration directory using the keytool utility that ships with the JDK:

# Linux
cd /srv/elvis-server/config
keytool -keystore keystore.jks -alias 1 -genkey -keyalg RSA -keysize 2048

# Windows
cd "C:\Documents and Settings\All Users\Elvis Server\Config"
keytool -keystore keystore.jks -alias 1 -genkey -keyalg RSA -keysize 2048

When prompted for 'first and last name' (CN), enter the domain name clients use to reach Assets Server (for example: assets.example.com).

For production, replace the self-signed certificate with one that is signed by a trusted Certificate Authority. Import the CA-signed certificate and its chain into the same keystore.

Then configure the following properties to match:

The HTTPS setup can also be done through the HTTPS Tools page in the Management Console.

2. HTTP Security headers

Modern browsers support several response headers that mitigate common web attacks. Assets Server provides configuration properties for these headers. The following are empty by default and should be set for a hardened deployment.

Cross-Origin-Opener-Policy

Cross-Origin-Resource-Policy

Permissions-Policy

Referrer-Policy

3. Cross-origin resource sharing

Set this to a comma-separated list of origins that legitimately need cross-origin access to the Assets Server API.

Example: security.accessControlAllowOrigin=https://assets.example.com,https://studio.example.com

Note: Wildcards (*) in subdomains are supported (for example: https://*.example.com).

4. Session and cookie security

Same-site cookie attribute

Available values:

• strict. Cookie is only sent for same-site requests. May break cross-site navigation to Assets Server (such as links from other applications).
• lax. Cookie is sent with same-site requests and top-level navigation (such as clicking a link). Balances CSRF protection with usability.
• none. Cookie is sent with all requests including cross-origin. This attribute provides no CSRF protection.

Cross-site integrations such as Studio Server, the InDesign plug-in, and custom API clients require none to function. Use 'lax' only when no cross-site integrations are in use. Assets Server provides a separate CSRF token mechanism regardless of this setting.

5. Authentication and password policy

These properties apply to internal users managed in Assets Server.

Note: This policy applies to new users and password changes. Existing users with weaker passwords are not affected until their password is changed.

6. Login throttling

The default login throttling settings (3 failed username attempts, 20 failed IP attempts, escalating block time up to 10 minutes) are appropriate for most deployments and do not need to be changed.

However, one setting requires attention when Assets Server runs behind a reverse proxy or load balancer:

7. E-mail transport security

If Assets Server sends notification or warning e-mails, the SMTP connection should be encrypted.

8. Logging and audit

9. Analytics

10. Infrastructure recommendations

Beyond Assets Server configuration, the following infrastructure practices further strengthen the security of an on-premise deployment.

Reverse proxy

Place Assets Server behind a reverse proxy or load balancer (such as nginx, Apache HTTP Server, or AWS ALB) for TLS termination, request filtering, and access control. The reverse proxy should:

• Terminate TLS with a certificate from a trusted CA.
• Forward only necessary ports to Assets Server.
• Set the X-Forwarded-For and X-Forwarded-Proto headers (and enable security.runningBehindLoadBalancer=true in the Assets Server configuration).
• Add additional security headers not covered by Assets Server configuration (such as custom CSP rules for the proxy itself).

Network and firewall

Only expose ports 80 (HTTP) and 443 (HTTPS) to external networks.

Ports that are used internally must not be accessible from the internet. For an overview of these ports, see Assets Server network ports.

File system permissions

Restrict access to the Assets Server configuration directory to the service account running Assets Server. In particular:

• cluster-config.properties.txt and node-config.properties.txt may contain passwords (SMTP, keystore).
• internal-users.properties.txt contains user credentials in clear text. If all internal users have been migrated to the Elasticsearch (Assets 6.120 or later) remove this file.
• The keystore file (keystore.jks) contains the TLS private key.

Elasticsearch

The embedded Elasticsearch instance binds its HTTP interface to 127.0.0.1 by default, making it accessible only from the local machine.

Verify that this has not been changed to a public interface. Elasticsearch does not require authentication by default and must never be exposed to untrusted networks.