Anti-Forgery Protection (CSRF)
Overview
Survanta uses ASP.NET Core anti-forgery validation on cookie-authenticated, state-changing MVC actions that opt into [ValidateAntiForgeryToken], including the documented access-token management writes. API-key, JWT, and public-token API controllers use non-cookie authentication and are explicitly ignored by anti-forgery where configured.
What Is a CSRF Attack?
A Cross-Site Request Forgery attack occurs when a malicious website tricks your browser into making a request to a web application you are already signed in to. Because the browser automatically sends your session cookie with every request, the web application might mistakenly treat the forged request as legitimate.
For example, without CSRF protection, a malicious site could embed a hidden form that, when you visit the page, silently submits a request to change your email address or delete your account using your active session.
How Survanta Prevents CSRF
Protected MVC forms include an anti-forgery token (also called a CSRF token), paired with the framework's anti-forgery cookie. The repository also configures the X-CSRF-TOKEN header for supported JavaScript requests.
When you submit a form, Survanta checks that:
- The submitted request token and anti-forgery cookie form a valid framework-generated pair.
- The token validation applies to the intended protected action; it is not a general proof of browser origin.
If either check fails — for example, because the form was submitted from a different website — the request is rejected and no action is taken. A clear error response is returned.
What This Means for You
As a user of Survanta:
- Normally the rendered protected form or project JavaScript supplies the token. Do not assume an action is covered without checking its server-side anti-forgery metadata.
- If you ever see an error message saying your form submission was rejected due to an invalid or missing token, the most likely cause is that your session has expired. Sign out, sign back in, and try submitting the form again.
- Bookmarking a form page and submitting it after a long delay may trigger this error because your session has refreshed. Simply reload the page and resubmit.
Coverage
Verified coverage includes state-changing MVC actions marked with [ValidateAntiForgeryToken], such as:
- Website login/register/logout writes where the action applies validation
- Plan/custom-order submissions that apply validation
- Access-token create, edit, revoke, link, and QR management writes
- Tenant and platform administrative writes that explicitly apply validation
Coverage must be determined from action metadata; this page does not claim every form/action in the repository is protected.
Frequently Asked Questions
Does CSRF protection slow down the website? Validation is a normal server-side framework check. No measured performance guarantee is documented here.
Can a third-party integration bypass anti-forgery protection?
Integration API keys, mobile JWTs, and public-token API schemes do not rely on ambient dashboard cookies and their API controllers can use [IgnoreAntiforgeryToken]. Cookie-authenticated browser writes should use the anti-forgery protection declared by their action.
What should I do if I keep getting anti-forgery errors? Check that your browser is accepting cookies from the Survanta domain (cookies are required to maintain the session and token binding). If the problem persists, contact your Tenant Admin or the platform team.