CSRF Token Generator

What is a CSRF token and why your app needs one

CSRF — Cross-Site Request Forgery, also called session riding or XSRF — is the class of attack in which a malicious page tricks a victim's browser into firing an authenticated request against a third-party site where the victim is already logged in. Because the browser automatically attaches the session cookie, the target server sees a perfectly legitimate request and executes it: transferring money, changing the e-mail on the account, granting admin privileges. The classical proof of concept is an image tag pointing to a state-changing GET endpoint, for example <img src="https://bank.com/transfer?to=attacker&amount=1000">. As soon as the victim visits the attacker's page, the GET fires and the money moves.

A CSRF token is a random, unpredictable string bound to the user's session that the server requires on every state-changing request (POST, PUT, PATCH, DELETE). Because a cross-origin attacker cannot read the victim's HTML or cookies, they cannot guess the token and the forged request is rejected. The token must come from a CSPRNG (cryptographically secure pseudo-random number generator) with at least 128 bits of entropy — Node's crypto.randomBytes(32), Python's secrets.token_urlsafe(32) or the Web Crypto crypto.getRandomValues() are appropriate sources.

The three canonical defense patterns

• Synchronizer Token Pattern — the server generates a token, stores it in the session, embeds it as a hidden field in every form and compares the submitted value on POST. This is what Django's CsrfViewMiddleware, Rails' protect_from_forgery and Spring's CSRF filter implement.
• Double Submit Cookie — the server sets the token as a regular (non-HttpOnly) cookie and the client mirrors it in a custom header such as X-CSRF-Token. Same-origin JavaScript can read the cookie; cross-origin scripts cannot, so the forged request will be missing the header.
• Origin / Referer validation — cheap fallback used by frameworks as a second line of defense; refuse any state-changing request whose Origin header does not match the application's host.

SameSite cookies and modern browsers

Since Chrome 80 (Feb 2020) cookies default to SameSite=Lax, which blocks cookies on most cross-site POSTs and mitigates a large fraction of CSRF vectors automatically. However, SameSite=Lax still allows top-level GET navigation to carry cookies, and not every user agent (legacy browsers, embedded webviews) enforces the same default. Defense-in-depth still requires CSRF tokens; OWASP, Mozilla and the SameSite RFC itself state SameSite is a mitigation, not a replacement.

SPAs, JSON APIs and the cookie question

If your API authenticates with Bearer tokens stored in localStorage, CSRF is structurally impossible because browsers do not attach Authorization headers cross-origin — the trade-off is XSS exposure. If you authenticate with HttpOnly session cookies (the more secure default), you need CSRF protection. A common SPA pattern: the server sets a XSRF-TOKEN cookie on login, the client reads it via JavaScript and echoes it back in the X-XSRF-TOKEN header on every mutating call. Axios, Angular's HttpClient and Laravel Sanctum implement this convention out of the box.

FAQ

Is SameSite=Lax enough on its own? It mitigates the vast majority of cross-site POST forgeries but does not protect against same-site sub-domain attacks, GET-based state changes, or browsers that ignore the attribute. OWASP recommends combining SameSite with explicit CSRF tokens.

Do I need CSRF on a pure JSON API? Only if the API is authenticated by cookies. If it uses Bearer tokens in the Authorization header (the OAuth/JWT style), the browser will not auto-attach the credential cross-origin and CSRF is moot.

How long should a CSRF token live? Bind it to the session — when the session expires or the user logs out, invalidate the token. Per-form (one-shot) tokens are stronger but break legitimate behaviours like the browser back button and concurrent tabs; per-session tokens are the usual compromise.

Does this generator send the token to a server? No. Bytes come from crypto.getRandomValues() in your browser and never leave the tab. Generate, copy, and embed into your form, session store or test fixture.