Odeley

Some days ago I stepped across this must-read tutorial:

Use attr_protected or we will hack you

To be honest: I really do not use all of these tips - I MUST do so!!

While reading it, some other do’s and dont’s came to my mind:

1. Users are only allowed to edit his/her ‘personal data’
2. Do not provide ’sensitive data’ via your REST XML response

1. Users are only allowed to edit his/her ‘personal data’
Just imagine, you are a user of an app and your user id is: 5.
With the url ‘/users/5/edit’ you may edit your ‘personal settings’.

Now try the url ‘/users/6/edit’.
Gosh!! It’s so easy to hijack another profile!

This is just a solution for my application. But I’m shure you get a hint what’s the idea behind it.

Of course, this does in most cases not only apply for the users resource.
You have to apply this pattern for all resources that are explicitly editable by one (…) user(s).

2. Do not provide ’sensitive data’ via your REST XML response
Rails is so great! Just look at following scaffold code - You get a REST XML interface by doing nothing!

def index
@users = User.find(:all)
respond_to do |format|
format.html # index.html.erb
format.xml { render :xml => @users }
end

But what will happen if one calls ‘/users.xml’ now?
The response will be a REST XML response with all non-private and private user data! Cool a list of all passwords, emails and credit card numbers of all your users!!!

def to_xml(options = {})
default_only = [:id, :name, :email]
options[:only] = (options[:only] || []) + default_only
super(options)
end

With overriding your to_xml() you just exclude the private data from your xml output!
Actually, after applying this recipe to my application I found it in this great book: Advanced Rails Recipes. Go for it!

I’m quite shure, the above code can be done more general, or just ported to a plugin. It’s just an advice what you have to keep in mind!

Come on! Now it’s your turn!
Some more recipes that apply to this topic!