Rails 4: Should a HEAD request not be handled like a GET for CSRF protection?

I am running a Rails 4 app in semi-production and I constantly get
exceptions from crawler bots that use a HEAD HTTP method, which causes
the
CSRF protection to kick in.

Shouldn’t HEAD requests normally be handled like GET requests?

I am not sure if I’m just being stupid or that hit is a bug somewhere.

Michiel

Michiel S. wrote in post #1093276:

I am running a Rails 4 app in semi-production and I constantly get
exceptions from crawler bots that use a HEAD HTTP method, which causes
the
CSRF protection to kick in.

Shouldn’t HEAD requests normally be handled like GET requests?

According to the Rails Guide it seems apparent that only GET request are
assumed to be safe.

http://guides.rubyonrails.org/security.html#csrf-countermeasures

3.1 CSRF Countermeasures
— First, as is required by the W3C, use GET and POST appropriately.
Secondly, a security token in non-GET requests will protect your
application from CSRF.

This document may be oversimplified, but judging by your question I’d
say it works pretty much as described.

On Wed, Jan 23, 2013 at 1:23 PM, Robert W. [email protected]
wrote:

http://guides.rubyonrails.org/security.html#csrf-countermeasures

3.1 CSRF Countermeasures
First, as is required by the W3C, use GET and POST appropriately.
Secondly, a security token in non-GET requests will protect your
application from CSRF.

This document may be oversimplified, but judging by your question I’d
say it works pretty much as described.

HEAD requests should not be CSRF protected, sounds like a bug needs to
be filed to me.