"The alternative would be to make Rails secure by default, but that would mean pretty much nothing would work until you explicitly granted access where necessar

"The alternative would be to make Rails secure by default, but that would mean pretty much nothing would work until you explicitly granted access where necessary." Given the amount of logging that occurs if you do set whitelist_attributes, it's not like this is a huge problem to fix. And, that logging (and the fact that your app mysteriously doesn't work) serve as a loud signal as to what action to take. On the other hand, the "insecure by default" solution is a silent and potentially catastrophic failure. Compare to how brake pads squeal: even the least mechanically savvy driver brings their car to a mechanic when their pads are running thin. Finally, the suggested fix (which, frankly, wouldn't have helped github) was simply to update the default generator to set whitelist_attributes, rather than merely including a comment to the effect. The "everything is broken" list would be introductory guides, full stop. So, novice developers would be held up until the guides could be updated with good security practice. Experienced devs, who supposedly all know about this, wouldn't have any problem on new apps. And the core team have basically said "meh, too much trouble." Apparently, they haven't been chasing html_safe! calls through their views, which is frankly way more of a pain than attr_accessble'ing data fields.