Thank you for reporting this issue! We've added this to our internal tracking system.
ID: PM-18645

Apple's approach is a good one.

They require every app accessing a password from the keychain, to have the user authorize either 'allow once', or 'allow always' access for the app requesting access. They must be keeping a mapping of which apps are authorized to access which passwords.

One workaround is using Caddy in a Docker container to access the vault through HTTPS with basic authentication. As long as Docker is restricted to privileged users, you can require a password for all requests when the vault is unlocked..

I've implemented it in this repo.

My use case is running the BW server on the target device, not on server, so the Caddy thing doesn't help. For now I do patch the source code to add an API key support. I've implemented it as a source generator which is less likely to break than a simple patch: https://github.com/RikudouSage/harbour-bitsailor/blob/master/patch/plugin.js

Running Docker container with -p 127.0.0.1:8080:8080 exposes it to localhost only, and Caddy's internal TLS encrypts the connection. It should work for your use case if I understand. Caddy supports header tokens or session certificates with mTLS, so its quite flexible.

It doesn't, it's running as part of another app on an end-user device, I cannot make assumptions, nor force the following to happen:

• caddy being installed
• docker being installed

I don't think docker is even available for the device I'm targeting.

Understandable! One idea would be to create your own isolated network namespace for the express server and expose it via a Unix domain socket. You can then add your preferred authentication method between the socket and the client. Tools like Caddy and Docker handle this automatically, but it may be possible to implement it yourself. Since you're allowed to modify the Bitwarden source code, you could implement the caching yourself — similar to how rbw handles it. I think your patch still leaves it open to apps that monitors data in transit.

Do you think this issue be resolved if bw serve supported Unix domain sockets with http://unix://? I think it would only require a small change.