Skip to content
WebAuditOS
Start free audit

Test your website now

Free, no card. We read only public pages.

Run free audit →

Security

What is CSRF, and do you still need a CSRF token?

Cross-site request forgery tricks a logged-in browser into sending a request it did not intend. How SameSite changed it, and when tokens are still needed.

Cross-site request forgery, CSRF, is an attack where another website makes a visitor's browser send a request to your site, and the browser attaches the visitor's cookies, so the action runs as them. SameSite cookies now block most CSRF, but cookie-based logins should still set SameSite explicitly and check a CSRF token or the Origin header on state-changing requests.

Published · Last updated

By Michal Měřínský. Audit methodology.

How it works

A user is logged into your site with a session cookie. They visit another page that contains a hidden form posting to your site's change-email endpoint. Their browser sends the request, attaches their cookie as it always does, and your server sees a valid, logged-in request. The attacker never sees the response. They only need the action to happen.

What SameSite changed

The SameSite cookie attribute tells the browser when to send a cookie on requests from other sites:

  • Strict: never on cross-site requests.
  • Lax: only on top-level navigations with safe methods such as GET. Cross-site form posts do not get the cookie. Chrome treats cookies without the attribute as Lax.
  • None: always, which requires Secure, and restores the old CSRF risk.
Set-Cookie: session=abc; Secure; HttpOnly; SameSite=Lax; Path=/

Do you still need CSRF tokens?

SameSite=Lax blocks most classic CSRF, but not everything:

  • Not every browser applies Lax by default, so set it explicitly.
  • GET requests that change state are still vulnerable under Lax. Never change data on GET.
  • Sibling subdomains count as the same site, so a compromised subdomain can still forge requests. For cookie-authenticated apps, add a second check on state-changing requests: a CSRF token, which most frameworks provide, or verifying that the Origin header matches your site.

When CSRF does not apply

If your API authenticates with a token in the Authorization header, set by your JavaScript rather than sent automatically as a cookie, a forged cross-site request has no credentials and classic CSRF does not work. The trade-off is that the token is stored somewhere JavaScript can read it, which raises the stakes of XSS.

What a scan can and cannot tell you

WebAuditOS checks observed Set-Cookie response headers for a SameSite attribute, fails cookies set to SameSite=None without Secure, and checks the Secure flag and clickjacking protection.

It cannot see whether your forms and API endpoints verify a CSRF token or the Origin header, and it does not attempt forged requests.

A pass means the observed response cookies satisfy the attribute check; JavaScript-set and authenticated cookies can remain unseen. Whether the chosen value fits each cookie's purpose still needs a review.

Short answers

Is CSRF still a problem? Less than before SameSite, but cookie-based apps still need protection.

Do single-page apps need CSRF protection? Only if they authenticate with cookies.

Lax or Strict? Lax for session cookies on most sites. Strict breaks logged-in links from other sites.

Is CSRF the same as XSS? No. CSRF borrows the user's session. XSS runs code on your page.

In the product

The checks this maps to

Every check named here runs on every scan, on every plan - what a plan changes is how many pages are crawled, how long the history is kept and what you can do with the result. These are the ids the findings carry, so you can match a line in a report to the explanation above.

Security

What is an XSS attack, and how do you prevent it?

Cross-site scripting lets an attacker run their script in your visitors' browsers. The three types, how frameworks protect you, and where XSS still gets in.

Security

What is a JWT, and how does JWT authentication work?

A JWT is a signed token carrying claims about a user. How it works, how to verify one, where to store it, and common mistakes.