Security
A backup system holds a copy of everything. Here’s how BackupProof is designed so that neither your storage provider, nor a compromised server, nor a crafted backup can turn that into a breach.
Reporting a vulnerability
Please report security problems privately using GitHub’s private vulnerability reporting, not in a public issue. Include the version, what you did and what happened. You’ll get a reply, and a fix and advisory will be published once it’s safe to do so.
Encryption
- Everything is encrypted on your server with XChaCha20-Poly1305 before it’s uploaded. Storage providers only ever see encrypted chunks.
- Chunk names are keyed BLAKE3 hashes, so storage can’t tell which files you have, and every chunk is checked against its name when read.
- Passwords are turned into keys with Argon2id. Each storage has its own random master keys; the password only unlocks them, so it can be changed without re-uploading.
- Lose the password and the recovery kit, and the data is gone. There’s no back door, by design.
Servers and the dashboard
- Servers connect out to the dashboard over HTTPS. They don’t listen on any port, so there’s nothing to open in a firewall.
- Each server has its own Ed25519 key, created on the server. Connection codes work once and expire after an hour.
- Backup data goes directly from each server to storage. The dashboard never sees file contents.
- The dashboard accepts a server’s proof only if it’s signed by that server’s key and is about that server’s own jobs.
- The first admin account needs a one-time setup code when created from another machine, so nobody on the network can claim a fresh install.
Accounts and roles
Anything that could run code on a server is limited to admins: commands and hooks, custom restore-test commands, moving items between servers, connecting servers, and reading arbitrary cloud-drive remotes. Operators can run backups and restore tests and change schedules; viewers can only look. The dashboard’s own data folder can never be backed up, imported from or used as storage by the built-in server.
Safe restores
- Restores write through a folder handle confined to the restore folder, and symbolic links are created last, so a crafted backup can’t write outside the folder.
- Restore tests only restore the backup named in a proof the dashboard has verified, and check its content root first.
- Databases are loaded into containers with no network, limited memory and CPU, and images pinned by digest.
Ransomware
Use S3-compatible storage with Object Lock (Amazon S3, Backblaze B2, Wasabi and others) and BackupProof writes every object locked for the period you choose. Until then it can’t be deleted or overwritten, even with the storage keys from a compromised server. Keep at least one copy away from the servers it protects.
Releases
Release binaries are built by GitHub Actions from a tagged commit, and published with a SHA256SUMS file. The install scripts check the download against it and stop on a mismatch. Every change runs tests on Linux (with the race detector) and Windows, go vet, golangci-lint and govulncheck. See verifying a download.
Fixed issues
| Version | Issue |
|---|---|
| 0.1.1 | Windows: the built-in server’s protection of its own data folder could be bypassed with an 8.3 short path to a folder that didn’t exist yet. Paths are now resolved through their deepest existing folder first. |
The changelog lists every security change.