I absolutely agree that there's no easy solution to this (or it would've been "fixed" already).

> some (most) people never open-source their app, and don't mind employees seeing it...

One of my concerns is that people believe it's only a risk if they ever open source their application. While most apps don't have to worry about a motivated attacker in reality, the risk isn't simply secure or unsecure.

It's more a case of 'more difficult' vs. 'much easier' to compromise. I fear many engineers don't think of securing their apps like this. I know I've only recently begun to understand this way of thinking about security and it's changed the way I code.

See also comments on HN[1] about an "old" post[2] from Hongli Lai (Phusion) about this topic.

[1] https://news.ycombinator.com/item?id=5007530

[2] http://blog.phusion.nl/2013/01/04/securing-the-rails-session...

Have you considered generating a key at first startup and storing it in a database? Or would that introduce too much unnecessary overhead while introducing an attack vector through the database?

The extra overhead could be kept pretty small. After being retrieved once, it can be cached in the memory of a server process. So, there's one short SQL query at process startup (or perhaps first request, depending on how you do it), and negligible overhead after that.

This is what I do, works great.

Most of my application secrets/configuration/keys/tokens are stored in the database.

The only one that's not is the information about how to connect to the database. That's stored in the DATABASE_URL environment variable and it's stored on each machine. envdir is used to start the apps, reading that environment data.

This seems reasonable, why not do it that way?

To a newbie like me, everything will "just work" in development. In production, I'll get a pretty explicit/precise error message.