All ASP.NET MVC Forms Need To Include Html.AntiForgeryToken() For Security

Having recently been implementing many new form pages in ASP.NET MVC, I’ve found myself over and over again adding the following two things to every form.

  • After Html.BeginForm() I Put @Html.AntiForgeryToken()
  • Add the Attribute [ValidateAntiForgeryToken] To Every Post Action Method

Before I was doing so much ASP.NET MVC, I would often see in Channel 9 videos, the presenter add the AntiForgeryToken() after the BeginForm() method on the cshtml razor page and say something like “you should always add this”.  I never saw them say “and don’t forget to add the attribute ValidateAntiForgeryToken to the controller POST method.

Just to be clear, below is what I’m talking about:



What this does is to make sure that the trusted browser that go the original GET page is the same one that is delivering the POST message.  Basically, this is all assuming that the end user is running a trusted browser.  It’s more about protecting the end user and not the server.  The idea is that a user who is using a browser they know is good (and trustworthy) will not be posting bad code back to the server.  You can read more details here:

If you look at the traffic in Chrome debug tools, you’ll notice an extra parameter on your form that the controller checks for as follows:


Hope this helps!

About Peter Kellner

Peter is a software professional specializing in mobile and web technologies. He has also been a Microsoft MVP since 2007. In addition, he’s a multi-course video author at Pluralsight. To read more about Peter Kellner and his experience click here. For information about how Peter Kellner might be able to help you with your project click here.

Follow me:


  1. Matt S. says:

    Great reminder to everyone. Thanks!

    What we *really* need here is a convention we can enable/disable that automatically emits the anti-forgery token *with* the BeginForm call. Furthermore, a revision to the ValidationAntiForgeryTokenAttribute would be nice so a developer could just apply it globally to the entire application and it would only work on POSTs, with options to have it ignore AJAX or look for the token in either the AJAX POST data or request headers.

    That would be great and avoid the need to have articles like this and the Channel 9 videos constantly reminding people to be sure they include this. It is important, so let’s remove the potential to forget it.

  2. What about a Web Forms application that uses ASP.NET Web API? How would one prevent CSRF in this case?


Get every new post delivered to your Inbox

Join other followers: