CSRF Tokens vs SameSite Cookies: Protect State-Changing Requests

A browser can attach authentication cookies to a request without the user consciously approving that action. Cross-site request forgery exploits the gap between an authenticated request and the user's intent. A server accepting a session cookie alone may not know what caused the request.

CSRF tokens and SameSite cookies address related parts of this problem, but they aren't interchangeable universal switches. Choose controls according to how the application authenticates requests and how browsers interact with it. Test actual state-changing workflows, including unusual paths.

Identify the operations that need intent protection

List actions that change data or authority: updating an email address, creating a payment instruction, adding a credential, deleting content, or changing a role. Review the HTTP methods and authentication mechanism each endpoint uses.

Don't make state changes through ordinary GET navigation. A link preview, crawler, or accidental visit should not perform a sensitive operation. Correct method use helps the design but doesn't by itself establish request intent.

The OWASP CSRF prevention guidance explains token and browser-oriented defences. Start with your framework's supported protection rather than inventing a custom token scheme from a short code example.

Understand the token's job

A CSRF token should be generated and validated according to the framework's security design, with the appropriate binding and handling. An unrelated random string sent back without a meaningful server-side check doesn't prove intent.

Keep tokens out of URLs where they may leak through logs, history, or referrers. Use the supported form field or request-header mechanism for the application. Review how tokens are issued, refreshed, and validated across normal navigation and asynchronous requests.

Don't confuse a CSRF token with an authentication credential. It supports a request-intent check within an authenticated workflow. The server still needs to verify who the user is and whether that user is authorised to perform the operation.

Use SameSite as part of the design

SameSite influences when browsers send cookies in cross-site contexts. The right setting depends on the application's flows, including external authentication and integrations. A stricter value can affect legitimate navigation; a more permissive value needs corresponding protection.

MDN's CSRF explanation describes the browser-side relationship. SameSite is a useful layer, but site boundaries and origin boundaries are not identical. A vulnerable or untrusted sibling subdomain can complicate assumptions.

Test the supported browsers and workflows. Don't declare protection complete merely because one cross-site form failed in one browser. Review login, logout, account linking, and administrative actions according to their actual consequences.

Add origin checks where appropriate

The server can use supported request-origin information as part of the defence. Define accepted origins explicitly and handle absent or unexpected values according to the framework and product requirements. Avoid substring matching that accepts an unrelated hostname containing your brand name.

Reverse proxies can affect how the application identifies its public host and scheme. Configure trusted proxy handling deliberately. A misconfigured origin check can either reject legitimate requests or accept more than intended.

Keep CORS separate. A CORS configuration controls aspects of cross-origin browser access; it is not automatically a complete CSRF policy. An attacker may not need to read the response to cause an unwanted state change.

Inspect the authenticated path locally

Use browser developer tools in an account and environment you control to inspect token submission, cookie settings, and rejected requests. Don't publish live session values or CSRF tokens in troubleshooting screenshots.

For a public route, HTTP Header Checker can inspect response headers, but it does not reproduce the signed-in browser flow or validate CSRF enforcement. A passing public check says little about a protected form's server-side token check.

Use Text Diff with sanitised middleware or configuration changes. Focus on exemptions, trusted origins, and endpoints bypassing framework protection. A small exception can matter more than a large unchanged security configuration.

Test rejection without side effects

In staging with synthetic accounts, submit requests with a missing token, invalid token, wrong origin, and a token from a different relevant context. Confirm the documented failure and verify that no data changed before rejection.

Also test valid requests after a session transition or page refresh. A defence that unpredictably blocks normal work may encourage developers to add broad exemptions. Fix the lifecycle issue rather than turning the protection off.

Cross-site scripting can undermine assumptions by running inside the trusted application context. CSRF controls don't replace output encoding or script security. See CSP report-only rollout for a separate layer addressing script execution policy.

Document the supported contract

Record which endpoints use cookie authentication, which protection applies, and how legitimate clients obtain and submit tokens. Review new endpoints against that contract. API clients using other authentication mechanisms may need a different analysis.

Keep tests in the normal release suite so a refactor doesn't remove enforcement silently. Include at least one check that observes persistent state after a rejected request, rather than testing only an error code.

Conclusion

Authentication identifies a session; CSRF protection helps establish request intent. Use framework-supported tokens, deliberate cookie policy, and appropriate origin checks. Verify rejected requests have no side effects and keep exemptions narrow enough to explain.