Honestly, this isn't even a matter of engineering.
I don't know the rails solution, but a quick-and-dirty solution in other frameworks is to use a decorator on your controller/views that does something like:
if request.session.userId == action.userId:
pass
else:
return SecurityExceptionResult
The example above is like 10 mins to code and put under test once you fill it in with the necessary stuff- You're probably going to want to log would-be security issues and gracefully handle the error.
With that said, user-identity does not belong in a URL. If you just did /user/edit (we assume all operations are performed on the logged in user) and then moved your security validation down a level to verify that session.userId == model.record.userId you'd be much better off.
What do you call the role of the individual whose job it is to implement account management? Do you not call that person an engineer? If not - whose responsibility would you say it is to ensure shit like this doesn't happen?
Good point, but I read "engineering doesn't matter" to mean you shouldn't spend a significant amount of time carefully designing a system that's likely to change. pg is absolutely correct in that sense.
My point was the amount of time required to prevent security holes like the ones outlined in the link are minimal - preventing them isn't going to stand in the way of an engineer implementing other features.
I don't know the rails solution, but a quick-and-dirty solution in other frameworks is to use a decorator on your controller/views that does something like:
The example above is like 10 mins to code and put under test once you fill it in with the necessary stuff- You're probably going to want to log would-be security issues and gracefully handle the error.With that said, user-identity does not belong in a URL. If you just did /user/edit (we assume all operations are performed on the logged in user) and then moved your security validation down a level to verify that session.userId == model.record.userId you'd be much better off.