SSL checklist for Ruby on Rails Applications

Cross posted from darthsid

The purpose of SSL is to provide a reasonable level of protection against eavesdropping and man-in-the-middle attacks. Although SSL provides a greater level of security, it introduces a lot of overheads and hence should be used sparingly. Two of the most common places to use SSL is for payment transactions and user registration/login.
This post intentionally focuses only on the Rails application as there are numerous post on the net for SSL setup on the server. Enabling SSL in a Rails application is really trivial and there are just a few points that need your attention..

1. Enabling SSL
a. Install the ssl_requirment plugin:

./script/plugin install git://

b. Include it in your application_controller.rb:

include SslRequirement

c. Specify actions that require SSL in their respective controllers. For eg. my session controller has the following line:

ssl_required  :new, :create if Rails.env.production?

d. Add the following line in development.rb to bypass SSL in development mode:

SslRequirement.disable_ssl_check = true

2. Gotcha’s
a. Include all submit actions in requirement
Any action that processes form data from a SSL page should also be added to the requirement. In the above example, the form on the login page(new action) is processed by the create action and hence it is also included in the requirement.
b. Ajax actions
Ajax actions on a SSL page should also use SSL and must be included in the requirement. At times you do not have a body for the Ajax action and it is rendered using it’s respective RJS template. In such cases create an empty action and include it in the ssl_requirement.
c. Mixed content
A lot of browsers show you a “Mixed Content Warning” if your SSL page references non-SSL assets. IE displays a scary looking confirmation dialog while Firefox and Chrome show a exclamation in the url bar. Any relative paths(eg. using _path helpers) on the page will automatically use the https protocol but any absolute paths(eg. using _url helper or by manually specifying as a string in link_to) will need to be changed to use https.
d. Asset host issue
If you are using Rails asset hosts and do not have a SSL certificate that supports wildcard(for subdomains), then you need to disable them for the SSL pages. Just add the following code to your production.rb:

ActionController::Base.asset_host = { |source, request|
  if request.ssl?
    "#{request.protocol}" % (source.hash % 4)

Replace “yourdomain” with your apps domain and “4″ with the number of asset hosts required.

The above should ensure that you have a proper SSL setup without displaying warnings to the user.

Tagged as:

14 thoughts on “SSL checklist for Ruby on Rails Applications

  1. I run SSL in production, development and test. Otherwise it is easy to miss URL which should be ssl.

    I handle development by using Nginx with a self signed cert proxied through thin. I can still use a debugger in thin.

    For test just alter the request in the setup/before `request.env["HTTPS"] = 'on'`

  2. Or you can just overwite ssl_required? in application controller

    def ssl_required?
    return false if ["development", "test"].include?(RAILS_ENV)

  3. Interesting stuff. One thing though is that I'd suggest that if SSL is required at all on a site to protect against MITM and eavesdropping attacks, it needs to be enabled on all actions and on all pages. The reason for this is that usually the session cookie will be scoped to be sent with all requests for pages on a a site, and if you only enable SSL for some actions, you're likely to end up with the session token being sent in the clear at some point.

    If this happens you remove a lot of the benefit of using SSL as it's usually trivial for an attacker to replay a valid session token and get unauthorized access to the site.

  4. It's true that implementing SSL site-wide would ensure better security but is it worth the heavy overhead that it will introduce? It might be better instead to avoid storing any sensitive data in cookies and expire them at shorter intervals, add a nonce implementation to deter replay attacks and use a CIM to store customer's confidential information. That should provide you with a reasonable level of security and even if an attacker manages to get unauthorized access it will not be possible for him/her to access your customer's confidential information.

  5. When you are using in your email views tags from rails, that conditions fails. You must validate if request object exists before the protocol:

    if request && request.ssl?

  6. Thanks a lot for the post. I agree that ssl certificates does bring a lot of overheads but i think that its worth it. At least we can assure the customers that their transactions are secure.

  7. I can tell what you mean. Great thoughts and they have really opened my own eyes to the opportunity of what you’re declaring. You definitely have got a lot of responses on this article!

  8. Thank you for your message. I agree that the SSL certificate
    that offers a great burden, but I think its importance. At least, we can promise
    customers that their business is protected.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>