Antiforgery token and cookie binding

30 min guided lesson · Read, predict, then run

External .NET10 SDK10.0.403. Real Kestrel, Microsoft.Data.Sqlite10.0.14 and HybridCache10.11.0. This Development-only owned-loopback fixture exposes deliberate fault controls; it is not a production deployment.

Read or download the complete SDK project, then follow its setup on your computer. The separate C# companion practice below runs in SharpRune’s .NET 9 console environment.

Define the ownership and result contract

Antiforgery validation checks a request token against the framework's relevant context, including its cookie. It addresses cross-site request forgery rather than authenticating a person or making a command single-use. The external fixture deliberately has an anonymous classroom counter, uses actual ASP.NET antiforgery services and increments only after validation succeeds. A valid pair can be submitted again and increment again. That reuse is expected behavior, not a cryptographic failure. The key provider is ephemeral so its protected payloads cannot survive replacement of that provider instance; the development process restart test therefore has a different boundary from ordinary repeated valid requests.

Trace the portable .NET9 console companion

The portable .NET9 console companion compares three Purpose records against the expected owner one and action publish. The first record matches both fields and prints True. Changing owner prints False, and changing action prints False. Record value equality supplies those results. These publicly known strings are not security tokens, signatures or antiforgery cookies, and an attacker could construct them freely. No server or cryptographic validator runs in this companion. Its narrow lesson is that matching one part of a context does not establish a full match; the real framework example is required for actual token issuance and validation.

using System;
using System.Linq;
using System.Collections.Generic;
using System.Globalization;
using System.Text;
using System.Text.Json;
using System.Threading;
using System.Threading.Tasks;

var expected=new Purpose("one","publish"); foreach(var offered in new[]{new Purpose("one","publish"),new Purpose("two","publish"),new Purpose("one","delete")})Console.WriteLine(offered==expected);
record Purpose(string Owner,string Action);

Walk through the actual external framework lab

Program.cs configures the X-CSRF-TOKEN header and a named classroom cookie, registers an ephemeral Data Protection provider and permits that cookie on the owned plain-HTTP development connection. /antiforgery/token calls GetAndStoreTokens and returns the request token while the response stores its paired cookie. /antiforgery/submit calls ValidateRequestAsync before incrementing submissions. Validation exceptions return400 and do not reach that increment. The actual repeated-valid-pair test can take the counter from one to two; missing or mismatched context leaves it unchanged. /antiforgery/count exposes that postcondition separately from response status, making handler execution directly observable in the fixture.

Keep failure and trust boundaries explicit

The cookie is explicitly nonsecure for this Development-only loopback exercise, and there is no authenticated business permission. Those choices must not be presented as production cookie guidance. A successful token check also does not consume a nonce or create a request receipt, so repeating an authorized business command would need its own semantics. Restarting the ephemeral provider invalidates old pairs rather than preserving a shared key ring across replicas. A deployed application must define TLS termination, persistent or shared key ownership, identity binding and authorization separately. No one response or token comparison establishes all those properties together.

Practice one: observe the real contract

Practice one: obtain a request token with a cookie jar, submit both, then submit that same valid pair again. Compare the accepted counter before and after both requests. Hint: expect two successful validations rather than assuming a token is consumed after its first use. Next omit the header or use an unpaired jar and verify400 with no additional increment. Keep all requests on the owned loopback fixture and use only its demonstration data. This exercise distinguishes valid contextual binding from replay prevention by observing both status and the actual side-effect counter.

Practice two: test another boundary

Practice two: save the original token and cookie, restart only the owned fixture, then try the old pair before obtaining a new one. Hint: the ephemeral Data Protection provider has changed, while the static demonstration counter has also restarted; do not compare its new zero baseline with an old process's cumulative count. Obtain a fresh pair and verify validation again. For a design extension, specify a durable command key and payload equivalence rule so duplicate business submissions can be recognized without expecting the antiforgery token to serve as a request identity or transaction receipt.

Interpret the evidence and defend the tradeoffs

A precise report names token issuance, paired-cookie handling, repeated valid requests, invalid combinations and the provider restart. It says the counter changed only after successful validation and explicitly allows another use of a still-valid pair. The portable record comparison establishes none of the cryptographic or browser properties. A senior explanation separates protection against cross-site submission from authenticated authority and from idempotent command execution. This distinction avoids the misleading claim that one valid security mechanism makes an operation safe against every kind of repetition, unauthorized caller or deployment key-lifetime failure. Each boundary needs its own implementation and test evidence.