Oh I see. I should have paid more attention to the devops tag, that's where you're coming from. I guess your security concerns are at a different level.
My comment was made in the context of JavaScript/React development, which incidentally is a big chunk of the developer community on DEV, so it's likely some of your readers will come from that background.
In that context, code often lives on public repositories on the web, e.g. GitHub, so it's very important to know that you should not commit secrets to the repo (a common mistake). Because the source is public, secrets in config files are a no-no. Typically when deploying on third party platforms (e.g. Heroku, Vercel, Netlify...), secrets are provided through environment variables, so that's what I was talking about.
Even in private repositories, it's very important not to commit secrets! What's the first thing you do when a service you use announces they've been accidentally logging passwords? You change your password immediately because the risk of your password ever having been stored on a web server in clear text is way too great, even for something like your personal Twitter.
How much worse would it be to store all of your database passwords or API keys unencrypted and unhashed on a third party's web server, where lots of their employees and contractors have access to the contents and where you have no visibility into their security practices?
Public or private repositories should still need to pull in the secrets at package time whether it is through files or not.
I'm not saying store secrets in Git, in the same way I'm not saying to store compiled code in Git. Git is the starting point where this article refers to the end point of how software should be configured when it is running on a host.
Oh I see. I should have paid more attention to the
devopstag, that's where you're coming from. I guess your security concerns are at a different level.My comment was made in the context of JavaScript/React development, which incidentally is a big chunk of the developer community on DEV, so it's likely some of your readers will come from that background.
In that context, code often lives on public repositories on the web, e.g. GitHub, so it's very important to know that you should not commit secrets to the repo (a common mistake). Because the source is public, secrets in config files are a no-no. Typically when deploying on third party platforms (e.g. Heroku, Vercel, Netlify...), secrets are provided through environment variables, so that's what I was talking about.
Even in private repositories, it's very important not to commit secrets! What's the first thing you do when a service you use announces they've been accidentally logging passwords? You change your password immediately because the risk of your password ever having been stored on a web server in clear text is way too great, even for something like your personal Twitter.
How much worse would it be to store all of your database passwords or API keys unencrypted and unhashed on a third party's web server, where lots of their employees and contractors have access to the contents and where you have no visibility into their security practices?
Public or private repositories should still need to pull in the secrets at package time whether it is through files or not.
I'm not saying store secrets in Git, in the same way I'm not saying to store compiled code in Git. Git is the starting point where this article refers to the end point of how software should be configured when it is running on a host.
Of course nobody should commit secrets to Git.