Correct me if I'm wrong, but isn't it pretty much always a bad idea to do it blindly, and the defaults are considered a security problem by the Rails project itself?
Hey now, don't go bringing facts into this thread -- I've already been downvoted hard for, apparently, not knowing what I'm talking about when saying that this is a security issue. So obviously the Rails team don't know what they're talking about either.
He just linked to an article that explains how to do it safely.
update to reply because of downvotes:
1) butterfly knives are very useful tools
2) mass assignment can be used safely out of the box in rails post v3.2.3. To use it, you have to explicitly add parameters to the whitelist or disable the whitelist. The article is there to explain why disabling the whitelist is a bad idea.
Sure, just like butterfly knives are safe because you can find some safety tips online.
Edit to reply to edits: Mass assignment is still dangerous "out of the box" since you have to switch on the whitelist behavior by calling attr_accessible on your model classes. In the security guide, the older, more dangerous, attr_protected is introduced first.
I think every rails dev should be familiar with the security guide, but more than that I wish that security was the default. While anybody is free to make an app as insecure as they wish, it should be the exception rather than the default.
You're talking about the old behaviour. New rails apps have config.active_record.whitelist_attributes set. That means that models without attr_acessible statements will throw an error if mass-assignment is attempted. IOW, they've done exactly what you asked for. They should have done it years ago, but they did the right thing after it blew up in their face.
I see. So that whole big mass-assignment security issue that exposed GitHub a while back -- that just didn't happen? Writing code in this style is perfectly safe?
Writing code in this style is perfectly safe if you do it correctly. GitHub didn't, so the defaults were changed to make it harder to do it incorrectly.
UPDATE: editing to reply since hn won't let me reply directly because the thread is to deep, yet I'm getting downvotes
It's not a tautology. Some things are safe even if you do them wrong. Some things are unsafe no matter how you do them.
Rails changed the defaults so that now you have to deliberately decide to do things unsafely. Rails before 3.2.3 fails un-safe in this scenario, but later versions fail safe. Rails 4 uses a different solution that's even harder to screw up.
"Writing code in this style is perfectly safe if you do it correctly."
That's a tautology.
In general you can't count on code being written "correctly", so this isn't a defense. It is better to have systems that degrade gracefully in the face of humans and their idiosyncrasies, rather than those that fail-unsafe, because you can't build your security system on the assumption that your code will be written by superhumans.
I hope you realize that this is the identical argument PHP developers made whenever someone brought up how insecure the base language, libraries, and configuration were.
Users of a framework should have to go out of their way to make themselves insecure. It shouldn't be insecure by default.
http://guides.rubyonrails.org/security.html#mass-assignment