restic REST server requires authentication and append-only scope review
restic REST server authentication, append-only authority, and 2026 count observations.
he restic REST server implements an HTTP backend for restic repositories. Restic encrypts repository data before sending it, so HTTPS is mainly about authentication and transport integrity. The server still controls who can read, write, delete, or prune repository files. That makes its access policy independent of restic's client-side encryption.
The project's README documents HTTP authentication through an .htpasswd file, an --append-only mode, and a warning about older versions that could disable authentication when the password file was missing. Recent releases changed the default to require authentication. The changelog also notes an append-only weakness around overwriting a repository config that was fixed. Those details make version and configuration review necessary.
What the counts show
On 2026-11-08, count-only probes used sub_type=all, page 1, and page size 1. app="rest-server" returned 17, title="rest-server" returned 1,449, and http.body="rest-server" returned 10,950.
The body and title values are broad string matches. They can include documentation, package pages, error messages, and unrelated services. They are not a count of exposed restic repositories. The app query is narrower but still needs ownership confirmation and an authentication test.
Separate the two authorities
Repository encryption protects the content from a server that stores ciphertext without the password. It does not prevent a server operator or an authenticated client from deleting snapshots, changing retention, or overwriting files. --append-only narrows the server's write authority, but it must be combined with a current version, a protected password file, and a backup policy that tests restores.
Authentication should be tied to the repository and the intended client. A shared password for every workstation makes revocation difficult. Use a dedicated credential per client where the deployment supports it, and place the server on a network that is reachable only by the backup clients and administrators.
Review checklist
Confirm the server version and whether .htpasswd exists before the process starts. Check that the password file is not writable by the web user and that missing authentication fails closed. Review --append-only, repository paths, TLS certificates, and any reverse-proxy authentication. Test whether a client can overwrite the repository configuration.
Build a restore test into the backup lifecycle. A successful upload is not proof that a snapshot can be read or that retention will preserve the needed copy. Monitor disk growth, failed prunes, authentication failures, and unexpected reads. Keep an offline copy of the repository password in a separate trust domain.
Defensive baseline
Use an authenticated, patched rest-server, restrict repository paths, and decide explicitly whether append-only or prune authority is required. Treat the backup server as a credential-bearing system and measure it with multiple ZoomEye fields while remembering that body matches are only leads.
References
Did you enjoy this article?
Recommend it — Standard Reader surfaces well-loved writing to more readers across the network.