Proxmox Backup Server: map datastore paths before trusting API tokens

Proxmox Backup Server is a management application and a storage service. Its API can create and inspect datastores, manage namespaces, run backups, and perform restores. That makes an exposed management surface more consequential than a simple file listing. The API token is only one input to the decision; its path-based permissions are another.

On 2026-11-08, ZoomEye count-only probes found 0 matches for app="Proxmox Backup Server", 42,093 for title="Proxmox Backup Server", and 105,639 for http.body="Proxmox Backup Server". The probes used sub_type=all, page 1, and page size 1. The zero application value does not establish that the product is absent. It shows a fingerprint gap that title and body observations may fill.

Tokens start without permissions

Proxmox Backup Server's user-management documentation states that newly generated API tokens do not have permissions by default. Access is role- and path-based, and a rule can bind a user, group, or token to an object path. Datastore and namespace paths are security boundaries, not merely labels. A token with broad rights on /datastore is different from a token limited to one backup namespace.

The API token is sent in an authentication header. That makes token storage, transport, and rotation part of the same review. A token used by a backup job should be limited to the source datastore and the operations that job performs. A read-only restore operator should not inherit the ability to create or delete namespaces.

Inventory the web and API paths

Start with the public host and identify whether the web interface, API endpoint, or both are reachable. Verify the TLS certificate and reverse-proxy routing. A proxy that exposes /api2/json while hiding the user interface still exposes the API.

List datastores, namespaces, users, groups, tokens, and ACL paths. For each token, ask who owns it, where it is stored, what tasks use it, and whether it can create, delete, verify, restore, or just read. Check whether a user can create a token that exceeds their own permissions. The effective permission command is useful for confirming a path-specific result.

Review remote and sync configurations. A backup server that pulls from another site or exports data may use credentials or network paths outside the web interface. Authenticate those paths with separate identities and log their changes.

Test the boundary in a safe order

Use a read-only test token against the intended datastore and confirm that it can inspect only the expected namespace. Then attempt a harmless operation outside the path and record the denial. Test a restore into a temporary target, not production data. Verify that the deletion path is blocked before testing any destructive permission.

Confirm that the web session is not accepted by the API if the API requires a token, and that an expired token is rejected. Rotate a test token and check that the old value fails promptly. Review audit logs for token creation, permission changes, namespace changes, and backup deletion.

Search: ZoomEye title matches for Proxmox Backup Server

The security question is not just whether a login page or product title exists. It is which datastore paths a reachable backup identity can modify or restore. The inventory should answer that before the first production credential is issued.

References

• Proxmox Backup Server, User Management
• Proxmox Backup Server, Configuration Files