This is in almost the same category as checking in your SSH private keys. I say almost because at least this one is somewhat understandable. From the perspectiv

This is in almost the same category as checking in your SSH private keys. I say almost because at least this one is somewhat understandable. From the perspective of of an app developer having everything in one place that you can deploy makes things easy. Hence it's included by default. Otherwise people would complain of losing the secret keys in between deploys (causing existing sessions to invalidate)[1]. Course none of that makes it acceptable (it's atrocious!). This is a perfect example of why code and config need to be kept separate[2]. If you have that as a mantra from the beginning then you don't have issues like this. [1]: In reality you should change your secret token regularly. The best approach is to accept a rolling window of old ones so you can age them out. Then you can pick how far back you want to support (eg. how stale a client's cookie can be). [2]: http://12factor.net/config http://12factor.net/config