> If someone found an exploit in your web app container [...]

A good pattern here is to reverse proxy all requests to the application through something like nginx. My applications tend to have a back-end application that is not accessible to the internet, with an nginx instance that proxies all API requests itself. Only port 80 is public facing. If someone can get console access to an nginx container and then use that to springboard to another container and get root access there (again, where the only open ports are ports 80, maybe 8000?) to get envvars, they should get access to it all.

If you are worried about secrets, check out the Docker Compose 3.9 documentation: https://docs.docker.com/compose/compose-file/compose-file-v3...

If your web app container can query the database, and your web app container is compromised, then yes the attacker could query the database. This is an issue independent of how you conveyed that access to the web app container.

If you want to limit the blast radius, you will need to find ways to limit what parts of the database the web app has access to.

if the exploit is in your web app, then you're already too late. Security is about layering. Which is why postgres/mysql have users and permissions. One thing I typically do is prevent DELETE statements from the web app db user. You can also prevent access to tables or even columns. Or you can go in the opposite direction and YOLO-it by putting SQLite right in your web app process, following the recent craze.

Environment variables are typically how secrets are used. Anything else is going to add further complexity and have another set of caveats. Env vars are simple and all devs (and programming languages) know how they work.