Why 'active_record.mass_assignment_sanitizer = :strict' in rails 3.2?

Question

By default, rails 3.2 sets active_record.mass_assignment_sanitizer = :strict in config/environments/development.rb. (See railcasts episode http://railscasts.com/episodes/318-upgrading-to-rails-3-2). Here it is:

# Raise exception on mass assignment protection for Active Record models
config.active_record.mass_assignment_sanitizer = :strict  

This makes the mass assignment error-prone in development and force to list every attributes for attr_accessible. What's the reasoning for doing this by default in rails 3.2(haven't checked if it is rails 4 as well)?

Answer 1

The link provided by Baldrick seems to be gone now. But I recently read a blog post that gives very useful context on the evolution of the mass assignment security issue in Rails: http://net.tutsplus.com/tutorials/ruby/mass-assignment-rails-and-you/

I'm not an expert on this issue but here's my understanding: Misconfiguring mass assignment in Rails could lead to really, really big security issues, all the more dangerous now that they've been popularized. Rails 4 attempts to patch over the biggest threats by requiring you to explicitly list the fields that can be mass-assigned right in the controller, where security concerns are easy for you to see and handle. But the handling of mass assignment in Rails 3 was more variable, and in many cases, if a parameter was submitted that wasn't on the attr_accessible whitelist (or was on the blacklist), Rails would simply skip over that parameter, without letting the developer know that anything had happened wrong.

This was a problem. If I'm writing an app that demands high security (or, these days, any level of security), if I've written a test to ensure that certain parameters are rejected, I want to know that they're being rejected. I'd much rather find out what Rails is doing sooner rather than later, so that I can adjust my code and plan future site sections accordingly. So, the mass_assignment_sanitizen = :strict setting makes this more vocal behavior the default.

You say that this setting makes mass assignment behavior more "error-prone" in development, as though this were a problem. I would think you would want your Rails app to be as error-prone and as vocal as it can be, during the development and testing phases, so that you learn about more of the potential problems in your code sooner on. So I appreciate the mass_assignment_sanitizer default.

Fortunately for both of us, Rails 4 has simplified this issue by taking a stronger stand in favor of strictness. Strict mass-assignment parameter sanitization, along with its vocal error-prone-ness, has become a default feature of the controller (since this issue never really belonged in the model in the first place) and provides you with a friendly private function where you can define any alternate behavior you need.