CSRF is a much more insidious vulnerability, and one that many developers do not even realize is there. It has to do with tricking someone with privileges to do something to an attacker's advantage. For example, Eve trick Carol, the admin, to delete Bob's account.
How does this work? It has to do with two things: every request that Carol makes to the web application is accompanied by her implicit trust. She's logged in as an administrator user, and she's allowed to do virtually anything. Another thing exploited in a typical CSRF attack is the improper use of GET requests and idempotence. As per the HTTP RFC (the official specification for HTTP), a GET request is not allowed to make any changes to the internal state of a web application. This is ignored by almost all web developers, GET requests are used as admin actions all the time. So all Eve has to do is trick Alice into clicking on a link to a URL like http://some.site/admin/delete/user/bob or something along those lines and there goes Bob's account. Since it's not immediately obvious, these bugs are prevalent in many web applications, it's been called the "lurking giant" by some, thousands and thousands of these vulnerabilities have been found in the past few years.
So what does Ruby on Rails do to mitigate these? First, no GET requests are able to change anything. Rails implements the RESTful pattern, and any request that makes changes uses the POST method (which is actually used to emulate other methods like PUT and DELETE, which web browsers do not support). So right there, the CSRF class of vulnerabilities is almost stamped out since there is no way to create a link to a POST request. But there is another way.
This token can be seen in your application layout. Do not remove this token if you edit your application layout file.
<%= stylesheet_link_tag "application", :media => "all" %>
<%= csrf_meta_tags %>
Again, this is another case of Rails having taken care of the vulnerability, but you should still know about it. CSRF vulnerabilities should never happen with Ruby on Rails, it's as simple as that. Rails used to be vulnerable, just like everything else, but since they cleaned up Rails rather significantly around the 3.0 mark, you just don't have to worry about it.
Another common vulnerability with web applications is the XSS, or cross-site scripting, vulnerability. Rails has got that covered though, and you can read all about it here.