Ruby on Rails 3.2.13 - Brakeman - Session secret should not be included in version control

Question

I have installed the latest version of the Brakeman gem to help me with Rails application security.

I have several Rails applications that I have on two servers, one for development and the other for production. When I ran the Brakeman reports on my applications, most of them flagged config/initializers/secret_token.rb with the following high security vulnerability.

Session secret should not be included in version control near line 7

This is the first time I have seen this error since I ran an older version of Brakeman months ago.

From what I have researched so far Rails automatically generated the secret token when rails new appname is executed. I was not aware of it until now. Apparently Rails does not protect this file where if I decided to move any of my applications to Github the information would be available to anyone at Github accessing the application. At this time I am not uploading to GitHub but I want information on how to move the secure_token from config/initializers/secret_token.rb in order to close the security hole in my applications.

One blog post I read suggested that I inject the secret token into an ENV variable. Will moving the statement from config/initializers/secret_token.rb to config/environment.rb solve the problem? If so I will add this task to my list of tasks in Rails development.

Any help would be appreciated.

Answer 1

That particular message in Brakeman was silenced for me when I put secret information into ENV variables, as you mentioned. Personally, I like to use the Figaro gem for this, but I think dotenv is popular as well.

Some other resources that may be of interest to you regarding this are:

• Code Climate blog entry: Rails Insecure Defaults blog entry on Code Climate
• StackOverflow thread: What should be removed from public source control in Ruby on Rails?

Answer 2

I'm not sure how moving the session secret to a different file would make a difference. Essentially, the secret token should be treated just like a password.

This blog post from Phusion explores a few different options for providing the session key at deploy time.