And what you should do with your apps’ sensitive data instead.
Today, I was in a conversation with some developers and we started talking about proper storage for the secrets that an application needs. These are things like database passwords, API keys, authorization tokens, encryption keys, certificates, etc. Collectively, we can refer to them as secrets.
As the name suggests, a lot of care should be put into protecting them, as if they were to end up in the wrong hands, they could cause your app’s security to be severely compromised — or worse.
When you’re building and deploying an app, how should you be managing secrets? And where should you be storing them?
I want to start by saying that there are multiple correct ways of dealing with that problem. In this article, we’ll be looking at three (plus a bonus one). However, there’s one way of managing secrets that is certainly wrong.
The Problem With Storing Secrets in Source Control
The mistake that many programmers (even experienced ones) make is to store secrets together with their code, checking them into source control (like Git). This is certainly the easiest, most convenient way to deal with the problem, but it’s a rather bad idea.
In short, don’t store your secrets in Git!
This applies to both secrets that are hardcoded into your application (such as putting the database password directly in the source code, which should be avoided at any cost), as well as keeping configuration files with secrets alongside your source code (such as .env or config.json files).
The most immediate reason why is connected to security. Source code repositories are meant to be shared — with your teammates, your company, or possibly with the entire world (as is the case for open source software).
In larger organizations, there are usually distinct development and operations teams, and developers don’t normally have access to production systems. Even in smaller teams where there’s less separation between dev and ops, it’s common to have different roles and individual responsibilities so that not everyone needs access to all secrets.
You may think that if you are the sole developer working on a project today, this may not apply to you, but that doesn’t mean others will not be joining you on that code base in the future — perhaps even temporarily (e.g. a contractor or a friend helping you solve one specific issue). Also, you will never know what could happen to your code, and it’s always possible it will end up as open source one day in the future.
Keeping secrets outside of Git is especially important for future-proofing. Git is designed to keep a persistent history of all your code changes, so once a secret is checked into source control, removing it requires rewriting history. That can be really hard if not impossible. Because Git is distributed, other developers may preserve your secret in their own local copies of the repo.
#git #software-development #programming #cybersecurity #security
