Ongoing open-source Rails secret_token vulnerability

Today I was re-alerted to a somewhat dangerous insecurity for open-source Rails apps if their Application.config.secret_token is kept under version control. The relevant file:

config/initializers/secret_token.rb

Rails itself generates this file in this way (without an entry in .gitignore) but it's still dangerous. There's lots of discussion here.

Presumably easily an environment variable could be set in config/application.yml (often kept out of version control) and retrieved at run time into config/initializers/secret_token.rb.

Remembering this would seem the only way to solve the problem and protect one's apps into the future from this known security vulnerability.

Here are Ruby on Rails Security Guide's recommendations:

'[P]lease secure your database configuration, e.g. config/database.yml, and your server-side secret, e.g. stored in config/initializers/secret_token.rb. You may want to further restrict access, using environment-specific versions of these files and any others that may contain sensitive information.' — per its Environmental Security section.

'If you have received an application where the secret was exposed (e.g. an application whose source was shared), strongly consider changing the secret.' — per its Session Storage section.

BTW, newly, Rails 4 has added Application.config.secret_key_base (described in the previous link and Guide for Upgrading Ruby on Rails' section, Action Pack).

'If you happen to share your code publicly, make sure your secret_key_base value is kept private.' — per this blog post.

Presumably, however, this new variable name setting does not remove the current security vulnerability either in Rails 3 or 4 since the Rails secret_token still is under version control.

Copyright (c) 2013 Mark D. Blackwell.