Hacker News Reader

Apparently this was a private repo, not a public one, but the attacker gained access.

It is still a very bad idea to store unencrypted keys in a private repository. You've now equated read access of your repository will whatever access that key has.

That doesn’t matter, best practice is storing them as variables that are injected upon deployment from a secret manager.

FWIW Dropbox had robust infrastructure to do exactly that when I was there as well as scanning for API keys in the main repository.

Certainly product code is going to conform to the pattern you've described, this sounds to me like some of the random non-product projects that may hit some external non-dbx API were not doing things properly and it flew under the radar for whatever reason. I highly doubt these API keys could have been used for much.

So yes, I agree with you, but here's some context.

Disclaimer: I haven't worked there since 2019

Reply on news.ycombinator.com