[GH-ISSUE #729] Attachments can be downloaded without authorisation #495

New issue

Closed

opened 2026-03-03 01:29:53 +03:00 by kerem · 4 comments

kerem commented

2026-03-03 01:29:53 +03:00

Owner

Originally created by @ntimo on GitHub (Nov 16, 2019).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/729

Hello,
Currently the API does not check if the user is authorized to download the encrypted attachment file via /attachments/.

It would be quite nice to have somekind of authentication here. So that it is not possible to download attachments without having a active session. I also noted that vault.bitwarden.com does the same :( .

Best wishes,
Timo

Originally created by @ntimo on GitHub (Nov 16, 2019). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/729 Hello, Currently the API does not check if the user is authorized to download the encrypted attachment file via /attachments/. It would be quite nice to have somekind of authentication here. So that it is not possible to download attachments without having a active session. I also noted that vault.bitwarden.com does the same :( . Best wishes, Timo

kerem closed this issue

2026-03-03 01:29:53 +03:00

kerem commented

2026-03-03 01:29:54 +03:00

Author

Owner

@mprasil commented on GitHub (Nov 17, 2019):

Yeah, unfortunately this is limitation on the Bitwarden side and I'm not sure what we can do about it. I assume the reason why it's implemented that way in the upstream is that they can offload attachment handling to "dumb" http server. (or even something like S3) On the plus side attachments are decrypted client side. So even if someone managed to guess the attachment URL (which is pretty hard with that uuid) they still wouldn't get the contents.

@mprasil commented on GitHub (Nov 17, 2019): Yeah, unfortunately this is limitation on the Bitwarden side and I'm not sure what we can do about it. I assume the reason why it's implemented that way in the upstream is that they can offload attachment handling to "dumb" http server. (or even something like S3) On the plus side attachments are decrypted client side. So even if someone managed to guess the attachment URL (which is pretty hard with that uuid) they still wouldn't get the contents.

kerem commented

2026-03-03 01:29:54 +03:00

Author

Owner

@ntimo commented on GitHub (Nov 17, 2019):

Maybe we could limit by IP address? I think that should work. So if we know that the user has a active session with IP xy then this IP is allowed to download attachments for this user.

@ntimo commented on GitHub (Nov 17, 2019): Maybe we could limit by IP address? I think that should work. So if we know that the user has a active session with IP xy then this IP is allowed to download attachments for this user.

kerem commented

2026-03-03 01:29:54 +03:00

Author

Owner

@mprasil commented on GitHub (Nov 17, 2019):

Not really. The active session is very loose concept. You can have mobile client logging in and then fetch the attachment hours later from completely different network.

@mprasil commented on GitHub (Nov 17, 2019): Not really. The active session is very loose concept. You can have mobile client logging in and then fetch the attachment hours later from completely different network.

kerem commented

2026-03-03 01:29:54 +03:00

Author

Owner

@mprasil commented on GitHub (Nov 27, 2019):

I'm going to close this as it's essentially working as intended. (trying to be upstream compatible)

@mprasil commented on GitHub (Nov 27, 2019): I'm going to close this as it's essentially working as intended. (trying to be upstream compatible)