Controller actions are protected from Cross-Site Request Forgery (CSRF) attacks
by including a token in the rendered HTML for
your application. This token is stored as a random string in the session,
to which an attacker does not have access. When a request reaches your
application, Rails verifies the received
token with the token in the session. Only HTML
and JavaScript requests are checked, so this will not protect your XML API
(presumably you’ll have a different authentication scheme there anyway).

GET requests are not protected since they don’t have side effects like
writing to the database and don’t leak sensitive information. JavaScript
requests are an exception: a third-party site can use a <script> tag
to reference a JavaScript URL on your site. When your JavaScript response
loads on their site, it executes. With carefully crafted JavaScript on
their end, sensitive data in your JavaScript response may be extracted. To
prevent this, only XmlHttpRequest (known as XHR or Ajax) requests are
allowed to make GET requests for JavaScript responses.

It’s important to remember that XML or JSON requests are also affected
and if you’re building an API you’ll need something like:

CSRF protection is turned on with the protect_from_forgery
method, which checks the token and resets the session if it doesn’t match
what was expected. A call to this method is generated for new Rails applications by default.

The token parameter is named authenticity_token by default. The
name and value of this token must be added to every layout that renders
forms by including csrf_meta_tags in the HTMLhead.