Custom App CSRF Tokens
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 | |
|---|---|---|
| CSRF 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 CSRF Tokens for steps to implement either pattern.
.
This section includes: