You raise an important issue, which I've written about before (http://blog.mhartl.com/2008/09/21/mass-assignment-in-rails-applications/ http://blog.mhartl.com/2

You raise an important issue, which I've written about before (http://blog.mhartl.com/2008/09/21/mass-assignment-in-rails-applications/ http://blog.mhartl.com/2008/09/21/mass-assignment-in-rails-a... and http://blog.mhartl.com/2008/09/21/finding-and-fixing-mass-assignment-problems-in-rails-applications/ http://blog.mhartl.com/2008/09/21/finding-and-fixing-mass-as...) and emphasize in the Ruby on Rails Tutorial book. Happily, in this case there is no cause for concern. (1) The book uses test-driven development for the most part; the snippet you pasted is just enough to get the "failed signup" test to pass, and is not the full implementation. (2) The code you copied doesn't even save the user, so there's no potential security breach at this point. (3) There's no admin attribute yet. (It's coming in Chapter 9.) (4) The User model is protected by attr_accessible in any case, as discussed in Chapter 5 (http://www.railstutorial.org/chapters/modeling-and-viewing-users-one#sec:accessible_attributes http://www.railstutorial.org/chapters/modeling-and-viewing-u...). There's no way to tell from inspecting a controller action whether or not there's a security breach at the model level. N.B. Just yesterday I exchanged notes with Yehuda Katz on this very subject; he and Carl Lerche both agree that Rails should close the attr_accessible security hole by default, much as Rails 3 now escapes the output of Embedded Ruby by default. My hope is that we'll see this implemented in Rails 3.x, for some value of x.