To protect against CSRF, Web developers have to go the extra mile. Of course, as with any vulnerabilities, doing things correctly from the get-go is extremely helpful In Rails, this means using the abstractions and DRY mechanisms available to you, particularly the form tag helpers form_for and form_tag.
Once forgery protection is enabled, your forms have a hidden ID field. This feature goes a long way in preventing CSRF attacks and, in applications that use RESTful resources, practically stops them altogether.
Enabling forgery protection is only one way to counteract security vulnerabilities in your Ruby code. You also need to pay attention to idempotence, or the ability to keep a value unchanged. In Ruby on Rails, idempotence is particularly important for the GET requests used in forms. Simply put, if a GET request to a server has idempotency, it means that any information sent via GET to a specific URL from a computer won't change any information on the server. Essentially, it will always carry the same information, no matter what.
Though HTTP referrers can be forged and won't help against CSRF attacks launched from your own site (via XSS), it's still be worthwhile to implement a check.By checking if the server from which the request originates is the same as the server your application runs on, you can determine if the request was generated from your site or not. If an HTTP request lacks a Referer header you can also tell it was generated by hand or from a location where Referer would make no sense (such as an email client).