Opting out of anti-forgery validation in Orchard

Anti-forgery tokens are a very important security feature of ASP.NET MVC and Orchard. Most of the time, you should keep them in place, and just let the system work its magic. There are a few rare situations however where it’s not the appropriate protection and you’ll want to disable it. Being too lazy to include the token in your ajax requests or your forms is of course not one of those situations.

One such real situation is when you’re building cross-server APIs, such as the ones I’m working on right now as part of the new deployment feature for Orchard. In this case, the two servers communicating will typically not share a common machine key, so there is actually no way of making the stock anti-forgery tokens work. The API calls still need to be protected of course, but that will be done through single-use, time-limited tokens built from a shared secret key, and transmitted as headers.

Unfortunately, the current implementation of anti-forgery in Orchard is a filter that protects all POST requests to controller actions, with only one way to opt out, through a declaration in the module’s manifest, which is way more heavy-handed than we need, because that would mean leaving all other non-API controllers unprotected.

WebAPI controllers are exempt from anti-forgery validation, but for technical reasons outside of the scope of this post, this is not an option, and I had to implement a regular controller.

There was clearly a missing feature in Orchard, so I went ahead and improved the existing ValidateAntiForgeryTokenOrchardAttribute so that it can now take a Boolean parameter. Setting it to false will instruct the anti-forgery filter to relax and let the request through.

[ValidateAntiForgeryTokenOrchard(false)]

This will be in Orchard 1.9, but please, please, please do not use this lightly: you need to be sure that other protections are there to replace anti-forgery.