What to Do Differently
The misuse of GET requests to access non-idempotent actions makes launching CSRF attacks easier. GET requests are very difficult to guard against CSRF attacks, especially when combined with XSS attacks on the same site. Even the most simple CSRF attack in an IMG tag can be devastating and can allow an attacker full access to every action.
As mentioned before, this application was generated before Rails 2.0 was released. This means the protect_from_forgery feature is not turned on. The protect_from_forgery generates authorization IDs with every form tag as hidden fields. This authenticity token is unique to each session, so it can be further used to match forms generated by Rails with authenticated user. A before_filter on all actions, called verify_authenticity_token, is added to check if the authorization ID is submitted with any POST and that it matches the authenticity token in the user's session variables. Without this form protection, any form may submit to non-idempotent actions.
RESTful Resources vs. CRUD
The application doesn't use the RESTful capabilities of Rails. While not necessarily "wrong," using RESTful resources preserves the non-idempotent rule for GET requests. Earlier Rails applications often used the word CRUD (Create, Read, Update and Destroy) to describe the similar process of manipulating ActiveRecord objects and their underlaying database rows. However, CRUD is a lower-level idea, and has no sense of how the database objects will be used. By using RESTful resources, the interface to these database objects is clear and consistent throughout the application and follows clear rules about idempotence.