What is the Authenticity Token in Rails?

Mateen Ulhaq
  • 24,552
  • 19
  • 101
  • 135
Ricardo Acras
  • 35,784
  • 16
  • 71
  • 112
  • 7
    Also see: "Why Does Google Prepend while(1) to their JSON response?" http://stackoverflow.com/questions/2669690/why-does-google-prepend-while1-to-their-json-responses – Chloe Feb 20 '13 at 03:56
  • I put this as an edit to the answer as well: a link to the github repo that allows a click-through to reference: https://pix.realquadrant.com/authenticity-token – satchel Jul 16 '21 at 01:50

10 Answers10


What happens

When the user views a form to create, update, or destroy a resource, the Rails app creates a random authenticity_token, stores this token in the session, and places it in a hidden field in the form. When the user submits the form, Rails looks for the authenticity_token, compares it to the one stored in the session, and if they match the request is allowed to continue.

Why it happens

Since the authenticity token is stored in the session, the client cannot know its value. This prevents people from submitting forms to a Rails app without viewing the form within that app itself. Imagine that you are using service A, you logged into the service and everything is OK. Now imagine that you went to use service B, and you saw a picture you like, and pressed on the picture to view a larger size of it. Now, if some evil code was there at service B, it might send a request to service A (which you are logged into), and ask to delete your account, by sending a request to http://serviceA.example/close_account. This is what is known as CSRF (Cross Site Request Forgery).

If service A is using authenticity tokens, this attack vector is no longer applicable, since the request from service B would not contain the correct authenticity token, and will not be allowed to continue.

API docs describes details about meta tag:

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 HTML head.


Keep in mind, Rails only verifies not idempotent methods (POST, PUT/PATCH and DELETE). GET request are not checked for authenticity token. Why? because the HTTP specification states that GET requests is idempotent and should not create, alter, or destroy resources at the server, and the request should be idempotent (if you run the same command multiple times, you should get the same result every time).

Also the real implementation is a bit more complicated as defined in the beginning, ensuring better security. Rails does not issue the same stored token with every form. Neither does it generate and store a different token every time. It generates and stores a cryptographic hash in a session and issues new cryptographic tokens, which can be matched against the stored one, every time a page is rendered. See request_forgery_protection.rb.


Use authenticity_token to protect your not idempotent methods (POST, PUT/PATCH, and DELETE). Also make sure not to allow any GET requests that could potentially modify resources on the server.

Check the comment by @erturne regarding GET requests being idempotent. He explains it in a better way than I have done here.

Stephen Ostermiller
  • 23,933
  • 14
  • 88
  • 109
  • 19,358
  • 4
  • 30
  • 33
  • 29
    @Faisal, is it possible then, for an attacker to simply read/capture the 'hidden' element of the form for Service A and get that unique token generated for the user - given that they have gotten access to the session started by the user for Service A? – marcamillion Oct 25 '10 at 22:18
  • 1
    For instance by hijacking the data returned from a debug function? Just a thought. – marcamillion Oct 25 '10 at 23:48
  • 14
    @marcamillion: If somebody hijacked your session at service A, then the authenticity token won't protect you. The hijacker will be able to submit a request and it will be allowed to proceed. – Faisal Oct 26 '10 at 07:02
  • Is it possible to detect when a CSRF attempt occurs? Maybe write to a log file or get a notification email ? – Zabba Jan 31 '11 at 01:07
  • 14
    @zabba: Rails raises an ActionController::InvalidAuthenticityToken exception if a form is submitted without the proper token. You can rescue_from the exception and do whatever processing you want. – Faisal Jan 31 '11 at 07:41
  • 1
    This behaviour has changed from Rails 3.0.4. http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails – Vijay Dev Mar 02 '11 at 10:16
  • 5
    re "Also make sure not to make any GET requests that could potentially modify resources on the server." -- this includes not using match() in routes which could potentially allow GET requests to controller actions intended to receive only POSTs – Steven Soroka Apr 25 '12 at 18:25
  • 109
    "...and the request should be idempotent (if you run the same command multiple times, you should get the same result every time)." Just a subtle clarification here. Safe means no side-effects. Idempotent means the same side effect no matter how many time a service is called. All safe services are inherently idempotent because there are no side effects. Calling GET on a current-time resource multiple times would return a different result each time, but it's safe (and thus idempotent). – erturne Aug 18 '12 at 16:25
  • only remeber if you are working in app that will make a remote post from another url (like Facebook iframe apps) you need to deactivate for this especific form. – Weverton Timoteo Jan 21 '13 at 13:36
  • 1
    GET requests shouldn't need to be idempotent. What if you are viewing a frequently updated feed, or a list of random things? – fabspro Feb 26 '13 at 12:03
  • Whats if request is coming from mobile platform instead of browser ? then how I gona handle this situation @Faisal – mfq Mar 08 '13 at 17:31
  • @mfq: If by mobile you mean something like API access, then you should be using API keys and secret API keys to authenticate and validate requests. The built-in CSRF token in rails does not work with API like requests – Faisal Mar 09 '13 at 16:37
  • @Faisal like facebook connect. I guess you are referring to outh token implementation ? – mfq Mar 09 '13 at 21:27
  • @mfq, that's one way to handle it. See this railscast for others: http://railscasts.com/episodes/352-securing-an-api?view=asciicast – chuck w Apr 03 '13 at 20:41
  • Note that by default, the statement, "Since the authenticity token is stored in the session, the client can not know its value." is not true. See [this answer](http://stackoverflow.com/a/8097243/21115). – davetapley Apr 16 '13 at 21:37
  • 2
    @dukedave in the context of a CSRF attack, the statement holds, because the client (in this case, javascript running in the malicious site origin) can not view the cookie from a different origin. Also, for anyone reading this way down here, dukedave says "by default", because the default session store is the cookie. Switching to any other session store will nullify this risk. – Faisal Apr 17 '13 at 06:51
  • Thx for the explanation - can you explain also why the authenticity_token is placed both in the meta tag, and also in each form, and what happens if an ajax response replaces a form on the page. Aren't there forms now with different authenticity_tokens? Are they one time use? And if so how do the other forms continue to work. – Brian Armstrong Jul 23 '13 at 06:55
  • 1
    @BrianArmstrong The meta tags do the exact same thing as the hidden form fields, however they exist as a way for javascript and ajax to have access to the token to send with AJAX requests. As for your other question, the token stays the same during a single session, so loading multiple forms won't generate multiple tokens, and they would all function as expected – Faisal Jul 23 '13 at 08:08
  • Gotcha. What if the page first loads with one authenticity token in the meta tag. Then you have two ajax forms on the page. The first runs and uses the authenticity token. The second then runs and tries to use the same token, but it has already been used. Is this possible or what am I missing? Thanks! – Brian Armstrong Jul 29 '13 at 22:26
  • Ahh, didn't realize the authentity_token stays the same for an entire session. Makes more sense now! – Brian Armstrong Jul 29 '13 at 22:45
  • 1
    Hey so if the cookie store holds the session couldn't a csrf attack just grab the token from cookie and then submit? – Austio Feb 12 '15 at 03:11
  • 3
    @austio, same-origin policy would prevent the javascript loaded by other origins (websites) from reading a cookie from a different domain. As an added precaution, you should make your session cookie "httpOnly", so that javascript can't read it at all. – Faisal Feb 12 '15 at 06:38
  • 1
    @Faisal PUT and DELETE are idempotent methods. So rails CSRF premise is not based on idempotence (state of system after a request has been executed). Rather it is proactive damage control that potentially "evil" code can cause to your system. – saihgala Dec 10 '15 at 15:33
  • @saihgala please check the comment by erturne. He explained it in a better way than I have. – Faisal Dec 10 '15 at 16:29
  • 2
    Can't a malicious page use JavaScript to issue a GET to the target page, extract the authenticity token from the returned HTML, and thus have the token for its own purposes? – Chuck Batson Feb 05 '16 at 19:23
  • Why the html include two token? head token and form token – Abel Feb 27 '16 at 21:59
  • @Faisal So turning csrf off for javascript requests is not safer..right?? – Abhilash Apr 22 '16 at 05:35
  • "GET request are not checked for authenticity token." ---> Would like to add that, apparently (if i read wikipedia correctly), this was the root cause of an ING security breach (ING is a bank). – BenKoshy Aug 17 '16 at 23:34
  • @ChuckBatson - I 100% agree, CSRF tokens are kind of pointless in this regard, an attacker can just grab it before making POST call. It does make it slightly harder and can't do it with just links, but require extra javascript steps, besides that its barely more secure it seems... – bjm88 Feb 28 '17 at 00:23
  • @bjm88 The same-origin policy prevents the attacker from doing so. – Demi Apr 25 '17 at 00:43
  • "Since the authenticity token is stored in the session, the client cannot know its value." This isn't true. The token is rendered as part of the form and that point the client *does* have access to it. – Dennis Hackethal Jan 04 '21 at 04:54
  • @Faisal -- I added a link to the github repo in a searchable environment to see the definition of authenticity token verification and ability to click to tests and references: https://pix.realquadrant.com/authenticity-token – satchel Jul 16 '21 at 01:47

The authenticity token is designed so that you know your form is being submitted from your website. It is generated from the machine on which it runs with a unique identifier that only your machine can know, thus helping prevent cross-site request forgery attacks.

If you are simply having difficulty with rails denying your AJAX script access, you can use

<%= form_authenticity_token %>

to generate the correct token when you are creating your form.

You can read more about it in the documentation.

  • 4,811
  • 2
  • 31
  • 31
Topher Fangio
  • 20,372
  • 15
  • 61
  • 94

What is CSRF?

The Authenticity Token is a countermeasure to Cross-Site Request Forgery (CSRF). What is CSRF, you ask?

It's a way that an attacker can potentially hijack sessions without even knowing session tokens.


  • Visit your bank's site, log in.
  • Then visit the attacker's site (e.g. sponsored ad from an untrusted organization).
  • Attacker's page includes form with same fields as the bank's "Transfer Funds" form.
  • Attacker knows your account info, and has pre-filled form fields to transfer money from your account to attacker's account.
  • Attacker's page includes Javascript that submits form to your bank.
  • When form gets submitted, browser includes your cookies for the bank site, including the session token.
  • Bank transfers money to attacker's account.
  • The form can be in an iframe that is invisible, so you never know the attack occurred.
  • This is called Cross-Site Request Forgery (CSRF).

CSRF solution:

  • Server can mark forms that came from the server itself
  • Every form must contain an additional authentication token as a hidden field.
  • Token must be unpredictable (attacker can't guess it).
  • Server provides valid token in forms in its pages.
  • Server checks token when form posted, rejects forms without proper token.
  • Example token: session identifier encrypted with server secret key.
  • Rails automatically generates such tokens: see the authenticity_token input field in every form.
Lutz Prechelt
  • 36,608
  • 11
  • 63
  • 88
Rose Perrone
  • 61,572
  • 58
  • 208
  • 243
  • 1
    Here is a version of this same explanation that is less precise but also less abstract: http://stackoverflow.com/a/33829607/2810305 – Lutz Prechelt Nov 20 '15 at 14:59
  • I'm not sure but, do modern browsers allow sending not idempotent requests(POST/PUT/DELETE) to another domain? I guess, there must be protection against such in things in browser itself – divideByZero Sep 22 '16 at 20:31
  • @divideByZero (ohh great name!) there is some protection in the form of CORS headers. A site can specify what domains it wishes to receive requests from (and certain browsers/apis are even more restrictive) but I'm not sure when this was adopted or if really old browsers all support it and one probably also wants to have this kind of protection in case the domain left their CORS settings to *. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS – Peter Gerdes Jun 29 '21 at 14:14

The authenticity token is used to prevent Cross-Site Request Forgery attacks (CSRF). To understand the authenticity token, you must first understand CSRF attacks.


Suppose that you are the author of bank.example. You have a form on your site that is used to transfer money to a different account with a GET request:

enter image description here

A hacker could just send an HTTP request to the server saying GET /transfer?amount=$1000000&account-to=999999, right?

enter image description here

Wrong. The hackers attack won't work. The server will basically think?

Huh? Who is this guy trying to initiate a transfer. It's not the owner of the account, that's for sure.

How does the server know this? Because there's no session_id cookie authenticating the requester.

When you sign in with your username and password, the server sets a session_id cookie on your browser. That way, you don't have to authenticate each request with your username and password. When your browser sends the session_id cookie, the server knows:

Oh, that's John Doe. He signed in successfully 2.5 minutes ago. He's good to go.

A hacker might think:

Hmm. A normal HTTP request won't work, but if I could get my hand on that session_id cookie, I'd be golden.

The users browser has a bunch of cookies set for the bank.example domain. Every time the user makes a request to the bank.example domain, all of the cookies get sent along. Including the session_id cookie.

So if a hacker could get you to make the GET request that transfers money into his account, he'd be successful. How could he trick you into doing so? With Cross Site Request Forgery.

It's pretty simply, actually. The hacker could just get you to visit his website. On his website, he could have the following image tag:

<img src="http://bank.example/transfer?amount=$1000000&account-to=999999">

When the users browser comes across that image tag, it'll be making a GET request to that url. And since the request comes from his browser, it'll send with it all of the cookies associated with bank.example. If the user had recently signed in to bank.example... the session_id cookie will be set, and the server will think that the user meant to transfer $1,000,000 to account 999999!

enter image description here

Well, just don't visit dangerous sites and you'll be fine.

That isn't enough. What if someone posts that image to Facebook and it appears on your wall? What if it's injected into a site you're visiting with a XSS attack?

It's not so bad. Only GET requests are vulnerable.

Not true. A form that sends a POST request can be dynamically generated. Here's the example from the Rails Guide on Security:

<a href="http://www.harmless.example/" onclick="
  var f = document.createElement('form');
  f.style.display = 'none';
  f.method = 'POST';
  f.action = 'http://www.example.com/account/destroy';
  return false;">To the harmless survey</a>

Authenticity Token

When your ApplicationController has this:

protect_from_forgery with: :exception


<%= form_tag do %>
  Form contents
<% end %>

Is compiled into this:

<form accept-charset="UTF-8" action="/" method="post">
  <input name="utf8" type="hidden" value="&#x2713;" />
  <input name="authenticity_token" type="hidden" value="J7CBxfHalt49OSHp27hblqK20c9PgwJ108nDHX/8Cts=" />
  Form contents

In particular, the following is generated:

<input name="authenticity_token" type="hidden" value="J7CBxfHalt49OSHp27hblqK20c9PgwJ108nDHX/8Cts=" />

To protect against CSRF attacks, if Rails doesn't see the authenticity token sent along with a request, it won't consider the request safe.

How is an attacker supposed to know what this token is? A different value is generated randomly each time the form is generated:

enter image description here

A Cross Site Scripting (XSS) attack - that's how. But that's a different vulnerability for a different day.

Stephen Ostermiller
  • 23,933
  • 14
  • 88
  • 109
Adam Zerner
  • 17,797
  • 15
  • 90
  • 156

Minimal attack example that would be prevented: CSRF

On my website evil.example I convince you to submit the following form:

<form action="http://bank.com/transfer" method="post">
  <p><input type="hidden" name="to"      value="ciro"></p>
  <p><input type="hidden" name="ammount" value="100"></p>
  <p><button type="submit">CLICK TO GET PRIZE!!!</button></p>

If you are logged into your bank through session cookies, then the cookies would be sent and the transfer would be made without you even knowing it.

That is were the CSRF token comes into play:

  • with the GET response that that returned the form, Rails sends a very long random hidden parameter
  • when the browser makes the POST request, it will send the parameter along, and the server will only accept it if it matches

So the form on an authentic browser would look like:

<form action="http://bank.com/transfer" method="post">
  <p><input type="hidden" name="authenticity_token" value="j/DcoJ2VZvr7vdf8CHKsvjdlDbmiizaOb5B8DMALg6s=" ></p>
  <p><input type="hidden" name="to"                 value="ciro"></p>
  <p><input type="hidden" name="ammount"            value="100"></p>
  <p><button type="submit">Send 100$ to Ciro.</button></p>

Thus, my attack would fail, since it was not sending the authenticity_token parameter, and there is no way I could have guessed it since it is a huge random number.

This prevention technique is called Synchronizer Token Pattern.

Same Origin Policy

But what if the attacker made two requests with JavaScript, one to read the token, and the second one to make the transfer?

The synchronizer token pattern alone is not enough to prevent that!

This is where the Same Origin Policy comes to the rescue, as I have explained at: https://security.stackexchange.com/questions/8264/why-is-the-same-origin-policy-so-important/72569#72569

How Rails sends the tokens

Covered at: Rails: How Does csrf_meta_tag Work?


  • HTML helpers like form_tag add a hidden field to the form for you if it's not a GET form

  • AJAX is dealt with automatically by jquery-ujs, which reads the token from the meta elements added to your header by csrf_meta_tags (present in the default template), and adds it to any request made.

    uJS also tries to update the token in forms in outdated cached fragments.

Other prevention approaches

Stephen Ostermiller
  • 23,933
  • 14
  • 88
  • 109
Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
  • Thank you, but your point about relying on same origin policy to not be able to just read the CSRF token first seems flawed. So first you saying you can POST to a different origin but can't read from it, seems weird but I guess that is correct, but you could inject an image or script tag with a get to the page and link a handler to parse response and get it yes? – bjm88 Feb 28 '17 at 00:29
  • 1
    @bjm88 inject the script where? On your site, or on the attacked site? If attacked site, allowing script injection is a well known security flaw, and effectively pawns the website. Every website must fight it through input sanitation. For images, I don't see how they can be used for an attack. On attacking site: you could modify your browser to allow the read, and thus auto pawn yourself at will :-) but decent browsers prevent it by default, give it a try. – Ciro Santilli OurBigBook.com Feb 28 '17 at 05:42

The Authenticity Token is rails' method to prevent 'cross-site request forgery (CSRF or XSRF) attacks'.

To put it simple, it makes sure that the PUT / POST / DELETE (methods that can modify content) requests to your web app are made from the client's browser and not from a third party (an attacker) that has access to a cookie created on the client side.

  • 14,322
  • 9
  • 47
  • 46

since Authenticity Token is so important, and in Rails 3.0+ you can use

 <%= token_tag nil %>

to create

<input name="authenticity_token" type="hidden" value="token_value">


Yuan He
  • 1,143
  • 1
  • 12
  • 14
  • This was helpful to me. I was actually trying to do `XSS` on the login page, not for nefarious purposes, but to create a new session with pre-filled user name. Now I know I can just use `value="token_value"`. – Michael Feb 24 '14 at 16:03

Beware the Authenticity Token mechanism can result in race conditions if you have multiple, concurrent requests from the same client. In this situation your server can generate multiple authenticity tokens when there should only be one, and the client receiving the earlier token in a form will fail on it's next request because the session cookie token has been overwritten. There is a write up on this problem and a not entirely trivial solution here: http://www.paulbutcher.com/2007/05/race-conditions-in-rails-sessions-and-how-to-fix-them/

  • 744
  • 8
  • 8

Methods Where authenticity_token is required

authenticity_token is required in case of idempotent methods like post, put and delete, Because Idempotent methods are affecting to data.

Why It is Required

It is required to prevent from evil actions. authenticity_token is stored in session, whenever a form is created on web pages for creating or updating to resources then a authenticity token is stored in hidden field and it sent with form on server. Before executing action user sent authenticity_token is cross checked with authenticity_token stored in session. If authenticity_token is same then process is continue otherwise it does not perform actions.

  • 8,882
  • 4
  • 49
  • 59
  • 2,932
  • 26
  • 20
  • 3
    Actually, isn't it the opposite ? GET is idempotent since its call shouldn't alter the state of the system, where PUT POST and DELETE verbs are NOT idempotent verbs since they alter the system state. I.E : authenticity_token is required in case of NOT idempotent methods. – Jean-Théo Jul 10 '14 at 09:26
  • 2
    @Jean-Daube, uma: idempotent means that if done twice, action only happens once. GET, PUT and DELETE *are* idempotent: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html The key property here is not idempotency, but if the method changes or not the data, which is called "Safe method" or not. – Ciro Santilli OurBigBook.com Nov 12 '14 at 20:14

What is an authentication_token ?

This is a random string used by rails application to make sure that the user is requesting or performing an action from the app page, not from another app or site.

Why is an authentication_token is necessary ?

To protect your app or site from cross-site request forgery.

How to add an authentication_token to a form ?

If you are generating a form using form_for tag an authentication_token is automatically added else you can use <%= csrf_meta_tag %>.

  • 6,569
  • 6
  • 41
  • 45
Pradeep Sapkota
  • 2,041
  • 1
  • 16
  • 30