Hiding Sensitive Information with Environmental Variables in Ruby

When I learned about user sessions in Sinatra. It involves setting set :sessions, true and assigning a secret key or word to that session.

Which had me thinking, what is the purpose of a secret word if it can be seen in a public Github repository? 🤔

A locked door that can easily be opened from the otherside

I heard of environmental variables and wanted to see if that would work here. I found several references to hiding sensitive information or API keys but none that fit in the context of my project.

With trial, error, and help from the Flatiron community, I figured out a way to hide sensitive information using environmental variables and the dotenv Ruby gem.

This post outlines how to set up environmental variables and some common gotchas that you may run into.

Note: I have written these directions in the context of the Sinatra project that is part of the Flatiron School Software Engineering course. The principles can work for other setups but may require revisions. If you are a Flatiron student working on this project, I highly recommend starting with the Corneal framework.

Setup

In your project repo’s, Gemfile add gem 'dotenv'.
In environment.rb ( this is located within the /config directory if you are using Corneal) add the following:

require 'dotenv'
Dotenv.load

I added mine after ActiveRecord::Base.establish_connection although you may be able to place it elsewhere within the file.

Run bundle install.
In the root directory of your project, if you do not already have them, create a .gitignore and .env file.
Within .gitignore add .env.Any files or directories listed within .gitignore are now not being tracked by Git. Changes to the .gitignore should be tracked, committed and pushed to your remote repo. Your .env should not be tracked, committed or pushed to a remote repo.

You can now use the .env file to keep API keys, session secrets and more. To do that, assign a key and it’s value using this syntax:

NAME_OF_KEY="This is the value of NAME_OF_KEY"

In your project files, reference that value by using ENV["NAME_OF_KEY"]. Since .env is not tracked or pushed to your remote repo, your code will only contain the reference to the value instead of the value it’s self.

Troubleshooting

I ran into several issues with my app not loading after starting the server. Installing the dotenv with gem install dotenv did not seem to work, but manually adding it to the Gemfile did.

If bundle install has been run and there are still unexpected results, double-check value names and where they are being called. For example, ENV["NAME_OF_KEY"] may need to be escaped if it is part of a string or within a .erb file.

Is anything safe?

Not really.

If you have previously committed or pushed sensitive information to a repo, consider it stolen. Update any passwords or generate new API keys as soon as possible. Sensitive information can be removed from Github, and previous commits can be reverted but that information may exist in a forked repo on someone else’s computer. Even if a repo is private, that information still exists on a server somewhere. If someone gained access to that server who shouldn’t (hello data breaches), they will have access to that information.

I am not trying to scare you. Just to think about what information you are posting on the web.

References

Photo by Michael Dziedzic on Unsplash