Intro

Any application that you create will have some secrets. Even a todo application which is storing information into a database has secrets. The credentials that you use to connect to the database is a secret for that application, isn’t it? But, many developers don’t pay enough attention to this part.

I have worked on many projects as a consultant. I would advise people on how to improve their applications. Sometimes, these improvements include code level improvements, architecture changes to infrastructure level changes.

I have seen secrets inside codebase which are actually used in production many times. These things scare me a lot. It's dangerous to commit and push these values inside the codebase.

Dot env files

Most of the modern frameworks allow you keep the environment variables out of github. Laravel for example uses .env files to load up secrets. And, although there is a .env.example file which should be a replica of the actual .env file minus the values. The idea is that if a developer clones a repository, he/she needs to copy the .env.example file and name it .env. And, the values which should go into the .env file. Some common ones will be the app key, database credentials etc.

Configs should have defaults

Laravel allows developers to use config variables which will pick up values from the .env file. But, if that value is not present, it will pick up a default value. For example the default port of MySQL database is 3306. Now, the database.php configuration file already has this. What that means is, if you have not changed the default, you don’t need to define it at all.

It allows the developer to get started quickly and define only the things which are beyond the default configuration.

Private repositories are not enough

If you feel that making a repository private will take care of security, I beg to differ. A private repository means that the code is not available in public. But, it doesn’t mean the secrets are secure. Sometimes, we want to share the codebase with developers. Let's say he will add a new feature. But, do you want them to actually get access to the credentials which are being used on production? Will you be comfortable with the fact that the developer has access to the live email sending service?

Also, you need to understand that deleting the secret code from the code doesn’t mean it no longer exists. A user can always revert to a particular commit and see the keys in history. This basically means, once a key gets committed even by mistake there is no way to get rid of it. You have to start a fresh repo.

Secrets are lying around

Believe it or not, secrets in codebase are a huge problem. Github has scanners which scans your code for such potential problems and warn you as well. Even then, if you go to Github and search for “removed aws keys” and filter the search by commits everything will be clear.

So, I hope I was able to make you understand the gravity of this problem and how you can work towards solving this problem. Most frameworks already have the basic checks in place so that the user doesn’t make some of the common mistakes. However, that doesn’t mean they can stop you from all the other possibilities. And hence, as a developer it’s your responsibility to keep these things in mind.

Do share your experiences on this particular issue. What you have seen, how you have solved the problem, anything. You can find me on twitter or on the Discord Bitfumes community.

Banner photo by Michael Dziedzic on Unsplash