The official way of preventing security risks with mass-assignment is using attr_accessible. However, some programmers feel this is not a job for the model (or at least not
Interesting gist from DHH on slicing in controller vs whitelisting alone:
https://gist.github.com/1975644
class PostsController < ActionController::Base
def create
Post.create(post_params)
end
def update
Post.find(params[:id]).update_attributes!(post_params)
end
private
def post_params
params[:post].slice(:title, :content)
end
end
Comment reinforcing the need to manage this within the controller:
https://gist.github.com/1975644#gistcomment-88369
I personally apply both - attr_accessible with slice to ensure nothing unexpected gets through. Never rely on blacklisting alone!
As of Rails 4, slicing the parameters will be the preferred method of dealing with mass assignment security. The Rails core team has already developed a plugin to deal with this now, and they are working on integrating support for nested attributes and signed forms. Definitely something to check out: http://weblog.rubyonrails.org/2012/3/21/strong-parameters/
@tokland your last comment is not correct to some extend. Unless your website has the browser as the only entry point where data comes in and goes out.
If your webapp has an API or communicates with other API's protection on the controller level leaves holes behind it and all data from other sources is not sanitised or checked. I recommend keeping the things as they are, turning on mass-assignment protection in application.rb and advancing ActiveSupport FormHelpers to work like Django/Python style.
Just removing the :name from the params hash works to prevent setting that attribute for that action. It works only for the actions you remember protecting.
However, this practice doesn't protect you from abuse using all the methods automatically added for associations.
class User < ActiveRecord::Base
has_many :comments
end
will leave you vulnerable for someone setting the comments_ids
attribute, even when you delete the comments
attribute from params.
Since there are quite a lot of methods added for associations, and since they might change in the future, the best practice is to protect your attributes on the model using attr_accessible
. This will stop these kind of attacks most effectively.
The problem with slice and except in controller might occur in combination with accept_nested_attributes_for
in your model. If you use nested attributes, you would need to slice parameters on all places, where you update them in controller, which isn't always the easiest task, especially with deeply nested scenarios. With using attr_accesible
you don't have this problem.