2.2 KiB
2.2 KiB
| type | subtype | title | summary | tags | scope | date | last_updated | last_reviewed | related | source | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| reference | api-integration | Vaultwarden vs Bitwarden Cloud — permission and feature parity gotchas | Verified differences between self-hosted Vaultwarden and Bitwarden Cloud that break security designs copied from Bitwarden docs — Edit permission includes delete, no deletion-restriction org policy, no Secrets Manager, trash never auto-purges by default. |
|
global | 2026-07-09 | 2026-07-09 | 2026-07-09 |
|
ruby-gems |
Vaultwarden Parity Gotchas
Bitwarden's official help docs describe Bitwarden Cloud. Vaultwarden reimplements the server and does NOT match on these points (verified 2026-07-09, vaultwarden discussions #6131, issue #6269):
- Edit collection permission includes deleting items. There is NO org setting to restrict item deletion to Manage-permission members (that toggle is Cloud-only). A "bot with Edit but can't delete" design is impossible server-side — enforce in your wrapper/OS layer.
- Manage permission is worse for least-privilege — it grants collection-membership admin.
- Secrets Manager does not exist in Vaultwarden. Don't plan it as a backend.
- Trash never auto-purges by default — permanent deletion only with
TRASH_AUTO_DELETE_DAYSset. (Cloud docs say 30 days.) Safer, but don't cite "30-day window". - Password history ("last 5") is written client-side into the cipher; compatible clients preserve it, raw API writes can clobber it. Likely works — verify per instance.
bwCLI API-key login still requiresbw unlock+ master password for vault data; the API key does not replace the master password. Non-interactive automation needs a protected--passwordfile.bw list items --searchdoesn't match custom fields — filter client-side on parsed JSON.- Maintainer (BlackDex) states Vaultwarden "does not support the full range of RBAC/GBAC/CBAC".
Rule of thumb: any "Bitwarden supports X" claim from bitwarden.com/help must be re-verified against the deployed Vaultwarden version before it becomes a security assumption.