SaaS CSRF prevention: protect state-changing requests
Prevent cross-site request forgery in SaaS apps with framework CSRF tokens, origin checks, safe HTTP methods, cookie settings and tested integration exceptions.
In this guide
What is CSRF, and which SaaS requests need protection?
Cross-site request forgery (CSRF) tricks a signed-in person’s browser into sending an unwanted request to a service that trusts the person’s automatically attached credentials, often a session cookie. Protect every state-changing action with a server-verified anti-CSRF control. Begin with the framework’s built-in protection, keep read-only navigation on safe methods, and do not assume CORS or a cookie’s SameSite setting alone prevents CSRF.
Use the framework’s built-in CSRF defense for cookie-authenticated actions
Enable the supported middleware and include its token in forms or an approved request header for state changes. The server must validate the token against the current session or another secure binding and reject missing or invalid values. Do not build a custom token scheme before checking what the framework already provides.
Keep GET and other safe methods free of changes
A link, image or browser navigation can trigger a GET without the person intending to make a change. Do not use GET to change passwords, update records, create API credentials, approve payments or log a user out. Reserve state changes for methods and handlers protected by the CSRF mechanism.
Map where the browser automatically attaches credentials
CSRF risk is highest when browsers attach cookies or other ambient credentials automatically. Identify session cookies, cross-origin form posts, account settings, billing actions and administrative workflows. A JavaScript API that explicitly adds a bearer token has a different CSRF profile, but token storage, XSS and authorization still need review.
| Action / route | Credential sent automatically? | Method and token control | Intentional cross-origin flow | Test and owner |
|---|---|---|---|---|
| Change recovery email | ||||
| Create or revoke API token | ||||
| Billing or administrator change |
How should a SaaS product handle tokens, origins and cookies?
Generate unpredictable tokens and verify them on the server
Use a framework-generated token bound to the user session or a signed, session-bound pattern. Keep it out of URLs, analytics and logs, and reject a state-changing request when the token is absent or invalid. Do not treat a token merely returned by the browser as trusted without checking its binding.
Use SameSite and origin checks as additional signals
Set an explicit SameSite policy that fits the product’s sign-in and integration flows, and consider validating `Origin` or `Referer` for sensitive browser requests. These checks can strengthen the defense but should complement a framework token strategy where cookie authentication is used. Test legitimate redirects and supported browsers before enforcement.
Document narrowly scoped cross-origin exceptions
A webhook receiver, embedded app or explicit cross-origin API may require different controls. Exempt only the exact route that needs the flow, and secure it with its intended authentication, request validation, CORS policy and logging. Do not disable CSRF middleware globally to make one integration work.
How do you verify CSRF protections in a SaaS application?
Test each high-impact state change
With authorized test accounts, check whether a request without a token, with a wrong token or from an unexpected origin is rejected. Cover account recovery, role changes, credential rotation, billing, exports and tenant administration. Verify that rejected attempts do not partially commit a change.
Check that cross-origin protections match browser behavior
Test cookie SameSite settings, origin validation, CORS configuration and intended integration paths together. CORS controls whether browser scripts can read many cross-origin responses; it does not by itself stop every cross-site request from being sent. A hidden form can still submit some requests even when the attacker cannot read the response.
Review the effect of XSS and service workers
An XSS flaw can often bypass CSRF tokens because injected code runs in the trusted site’s origin and may read page tokens or submit requests. Review scripts, service workers and browser extensions within the threat model, and fix XSS separately. CSRF controls do not replace authentication or object-level authorization.
SaaS CSRF prevention questions
Does CORS prevent CSRF?
No. CORS mainly controls whether browser code from another origin may read a response. It does not block every simple form submission or other request that can carry cookies. Use server-side CSRF defenses for cookie-authenticated state changes.
Is SameSite enough to protect every endpoint?
No. SameSite is useful defense in depth, but product flows, browser behavior and cross-origin use vary. Use framework CSRF protection for cookie-authenticated actions and test the complete workflow.
Do bearer-token APIs need CSRF tokens?
It depends on how the browser obtains and sends the credential. A token explicitly attached by same-origin application code is not automatically sent like a cookie, but credentials stored in cookies or other ambient browser authentication can reintroduce CSRF risk. Review the real client and storage design.
Can we exempt a webhook from CSRF checks?
A machine-to-machine webhook may use a dedicated signature or authentication scheme instead. Exempt only that route, verify the message according to the provider’s documented method and test replay and authorization behavior; do not remove CSRF protection application-wide.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- OWASP Cross-Site Request Forgery Prevention Cheat SheetOWASP Foundation