Proxmox Backup Server: map datastore paths before trusting API tokens

Proxmox Backup Server is a management system and storage service that offers API functions for creating and inspecting datastores, managing namespaces, executing backups, and restoring data. Exposing the management surface raises security concerns beyond a basic file listing. API tokens are just one factor in access decisions; path-based permissions are equally important.

On November 8, 2026, ZoomEye automated scans identified 0 occurrences of the application "Proxmox Backup Server," 42,093 mentions of the title, and 105,639 instances of the HTTP body containing "Proxmox Backup Server." The absence of an application value does not indicate the product's nonexistence; it highlights a gap in fingerprinting that may be addressed by title and body observations.

API tokens begin with no permissions by default. Access is granted based on roles and paths, allowing a rule to associate a user, group, or token with a specific object path. Datastore and namespace paths serve as security boundaries rather than mere labels. A token with extensive permissions on "/datastore" differs significantly from a token restricted to a single backup namespace.

The API token is transmitted within an authentication header, which implies that token storage, transmission, and rotation are integral aspects of the security review process. A token utilized by a backup job should be limited to the source datastore and the specific operations performed by that job. A read-only restore operator should not be granted the authority to create or delete namespaces.

To assess the security of the Proxmox Backup Server, it is essential to examine the web and API paths. Begin by identifying whether the public host allows access to the web interface and API endpoint. Verify the TLS certificate and reverse-proxy routing. A proxy that exposes "/api2/json" while concealing the user interface still grants access to the API.

List all datastores, namespaces, users, groups, tokens, and ACL paths. For each token, inquire about its ownership, storage location, associated tasks, and capabilities, such as creating, deleting, verifying, restoring, or merely reading. Check if a user can generate a token exceeding their own permissions. Utilize the "effective permission" command to validate a path-specific outcome.

Review remote and synchronization configurations. A backup server that retrieves data from another location or exports information may utilize credentials or network paths distinct from those used within the web interface. Authenticate these paths with separate identities and document their changes. Conduct testing in a controlled order.

Utilize a read-only test token against the intended datastore to confirm that it can inspect only the expected namespace. Then, attempt a harmless operation outside the specified path and document the denial. Test a restore into a temporary target rather than production data. Verify that the deletion path is blocked before testing any destructive permissions.

Confirm that the web session is not accepted by the API if the API necessitates a token, and that an expired token is rejected. Rotate a test token, and ensure that the previous value fails promptly. Examine audit logs for token creation, permission modifications, namespace changes, and backup deletions. Search for instances containing "Proxmox Backup Server" in ZoomEye's title matches.

The primary security concern lies not only in the presence of a login page or product title but also in determining which datastore paths a reachable backup identity can modify or restore. This inventory should be completed before issuing any production credentials.