That guide is wild. By default it allows public registration, shows password hints, requires a reverse proxy for robust TLS but then passes tokens via GET params, runs in the container as root. Recommends fail2ban because it doesn't have any coverage against brute force. Recommends using a custom path for security.

This feels less like a guide on hardening Vaultwarden than a guide on why I should be skeptical about it.

I’m not an expert with web sockets or web development - but re: Get Params, Vaultwarden has to follow the API of the upstream Bitwarden implementation:

https://github.com/dani-garcia/vaultwarden/discussions/1549#...

The upstream also had this issue, which appeared to be closed without a PR:

https://github.com/bitwarden/server/issues/3650

Requiring a reverse proxy for TLS is pretty standard, but the rest of those findings are egregious (if they haven't been addressed yet.)

The part I found jarring was that it will totally do TLS for you but using a TLS stack they don’t recommend, and if you put it behind a reverse proxy you also need to know to do custom log redaction to avoid logging tokens.

Those problems are endemic to all web apps.

e.g. You can’t just provide software to people that obtains TLS certs on their behalf: you have no idea how their infra is setup.

Hosting any app on your own infra is a serious skill set.

> Those problems are endemic to all web apps.

No, they’re not.

They’re design choices where the default that has been chosen is dangerous for somebody deploying the software. Plenty of web apps do not have those pitfalls.

Since it's authored by the vaultwarden collaborators, I would not trust the project any bit of my passwords.

Pretty similar experience for me, albeit I've only been managing it for about a year.

Restore from backup testing was straightforward. We haven't had any problems w/ the application itself.

I used that that hardening guide for my setup. The one I manage is exposed to the Internet and I'm bringing traffic into it via a reverse proxy.