Custom App XSRF Tokens
Prerequisites: CMS 10.6.498 must be installed. See CMS Statistics for details to check your version
The CMS ships with two supported patterns. Both rely on the same middleware; they differ only in whether they add a second MVC-level validation layer. For a complete, working example of both patterns, see the Reference Implementation section.
How CMS Anti-Forgery Middleware Works
When a user loads a CMS page, the middleware writes an XSRF-TOKEN cookie to the web browser. On every subsequent non-GET request, the client must echo that cookie value in an X-XSRF-TOKEN request header. The middleware compares the two; a mismatch (or missing header) returns a 403 Frobidden error and the controller action never runs.
The cookie and header names default to XSRF-TOKEN / X-XSRF-TOKEN but a CMS administrator can override them via local-appsettings.config. Custom apps must read the configured names at runtime, not hard-code them.
Choose a Pattern
| Option A: CMS Middleware Only | Option B: MVC + CMS Middleware | |
|---|---|---|
| XSRF layer | CMS OWIN middleware | MVC [ValidateAntiForgeryToken] + CMS OWIN middleware |
| Token source | XSRF-TOKEN cookie → X-XSRF-TOKEN header | __RequestVerificationToken hidden field + header |
| Failure response | 403 | 403 (middleware) or 500 (MVC attribute) |
| When to use | AJAX-only actions | HTML form submissions where a second independent layer is preferred |
ajaxSend hook. The CMS middleware runs on every POST regardless of pattern used by the action.See Implementing Custom App XSRF Tokens for steps to implement either pattern.
.
This section includes: