This is by no means a way to bash on Rails. I actually like Rails and think it's great. I also think the conventions are great and everyone should follow them!
I am just using it as an example since I am familiar with it and it's strong on the (good) conventions... which I am using to exploit.
And calling the programmers inept might be a bit harsh, but their lack of knowledge combined with the conventions followed is what I am pointing out here.
I am not going to mention any names with this issue still open, but this was previously in Diaspora (hoped it's fixed by now). Seen it in soooo many places, it's not funny. Especially when they manage user data and payments.
It's a combination of both Rails convention/predictability and the programmers lack of knowledge.
What I am referring to is the rails CRUD controller conventions to make the controllers RESTFul.
Basically what I am talking about is authorization before CRUD:ing a Resource.
Now, I purposfully didn't say authentication, but authorization.
They do not check that the resource being "worked" on belongs to the authenticated user. However in most cases they do check that the user is authenticated. At least it's a start ;-)
In rails terms..
.
What they use is
@place = Place.find params[:id]
@place.destroy
What they should have done (I am sure there are better ways)
@place = current_user.places.find params[:id]
@place.destroy
So they are not authorizing that the user have access to the resource, just authenticating the user.
Basically, I can log in in my account (hell, any account). And CRUD other peoples stuff.
And since Rails is using jQuery as a default. Things become quite easy for us.
jQuery.post("/places/18494", {_method: "PUT", places: {title: "Slaughter house", id: "18494"}, id: 18494}, null, "script")
jQuery.post("/places/17760", {_method: "DELETE"}, null, "script")
I can easily check the javascript code and how forms are built in the html source to see how the parameters is built and the name of the attributes.
With the naming conventions following that, things become much easier than having to guess all resources and their actions or go through obfuscated javascript to find the destroy action if it was renamed into something else.
So.... authorize your users access for the resource, not just authenticate. And follow the conventions. Still.
On a side note. I am looking for a job.
I'd like the position of a Mobile & Tablet Product Manager - But I'm iOS developer myself, so I can basically estimate, build and to some extent design the things I request as product manager ;-). Can also code on the API (familiar with Sql, Redis and etc - Would prefer it as well).
I'd also recommend looking into using role based authorization (ACL) by using cancan, acl9, or other gems.