Guidance on Appropriate Value for First Parameter in AntiForgery.GetTokens

Abani · March 2, 2026, 10:23am

We are currently using the following code in our application:

ServiceStack.Html.AntiXsrf.AntiForgery.GetTokens(null, out newCookieToken, out formToken);

In this implementation, we are passing null as the first parameter to the GetTokens method.
Could you please tell us what is the best practice?

mythz · March 2, 2026, 1:23pm

This is an old implementation of ASP .NET Framework MVC AntiForgery class:

github.com/ServiceStack/ServiceStack

ServiceStack/src/ServiceStack.Razor/Html/AntiXsrf/AntiForgery.cs

939ba15da


      
          /// <summary>
          /// Generates an anti-forgery token pair (cookie and form token) for this request.
          /// This method is similar to GetHtml(), but this method gives the caller control
          /// over how to persist the returned values. To validate these tokens, call the
          /// appropriate overload of Validate.
          /// </summary>
          /// <param name="oldCookieToken">The anti-forgery token - if any - that already existed
          /// for this request. May be null. The anti-forgery system will try to reuse this cookie
          /// value when generating a matching form token.</param>
          /// <param name="newCookieToken">Will contain a new cookie value if the old cookie token
          /// was null or invalid. If this value is non-null when the method completes, the caller
          /// must persist this value in the form of a response cookie, and the existing cookie value
          /// should be discarded. If this value is null when the method completes, the existing
          /// cookie value was valid and needn't be modified.</param>
          /// <param name="formToken">The value that should be stored in the &lt;form&gt;. The caller
          /// should take care not to accidentally swap the cookie and form tokens.</param>
          /// <remarks>
          /// Unlike the GetHtml() method, this method has no side effect. The caller
          /// is responsible for setting the response cookie and injecting the returned
          /// form token as appropriate.
          /// </remarks>

Where:

The anti-forgery token - if any - that already existed for this request. May be null. The anti-forgery system will try to reuse this cookie value when generating a matching form token.

Passing null is valid, but the best practice is to pass the existing cookie token value if one already exists for the current request/user session.

When you pass null, the system will always generate a new cookie token, which means you must always update the response cookie.
When you pass the existing cookie token, the system can reuse it if still valid, and newCookieToken will be null on output - so no cookie update is needed, reducing unnecessary churn.

It’s likely over a decade since I’ve used this, but the idea is you only need to set a new cookie token if one hasn’t existed. Here’s a good old video from Troy Hunt explaining how it works and that it’s recommended to use an existing cookie token if it exists.

If you set null you’re basically telling it to create and set a new cookie token each time:

// Read the existing cookie token (if any) from the request
string existingCookieToken = Request.Cookies["__RequestVerificationToken"]?.Value;

string newCookieToken, formToken;
AntiForgery.GetTokens(existingCookieToken, out newCookieToken, out formToken);

// Only update the cookie if a new one was issued
if (newCookieToken != null)
{
    Response.Cookies["__RequestVerificationToken"].Value = newCookieToken;
}