CSRF testing: how pentesters check tokens, SameSite and login CSRF

CSRF stands for cross-site request forgery. It makes a signed-in user's browser send a request the user did not intend. The OWASP WSTG describes it as "an attack that forces an end user to execute unintended actions on a web application in which they are currently authenticated."

CSRF testing checks that every state-changing request needs proof that it came from your own pages. Testers check tokens, SameSite cookies, JSON endpoints and login CSRF, and prove each result in a real browser. These checks are part of web application penetration testing.

How does CSRF work?#

CSRF works because browsers attach cookies to requests automatically. If a page on another site can make the browser send a request to your app, the cookie goes along. The app then acts as the signed-in user.

Three conditions must hold:

1. The action changes state (change email, transfer funds, add a user).
2. The app identifies the user only by cookies, with no extra proof.
3. The attacker can predict every parameter in the request.

An anti-CSRF token breaks condition 3. A SameSite cookie breaks condition 2 in many cases.

What do SameSite cookies change?#

SameSite tells the browser when to send a cookie on cross-site requests. MDN explains the three values:

• Strict: send the cookie only for requests from the same site.
• Lax: also send it on cross-site top-level navigations that use a safe method. MDN says this "essentially means that the request causes the URL shown in the browser's address bar to change." A cross-site fetch() or <iframe> does not qualify. A cross-site form POST does not qualify either.
• None: send it on all requests. It needs the Secure attribute.

If the attribute is missing, behavior depends on the browser. MDN says "Some browsers use Lax as the default value if SameSite is not specified." The Chromium project documents its move to Lax-by-default. MDN adds that this default is more permissive than an explicit Lax: cookies are also sent on cross-site POST requests made within two minutes of the cookie being set.

Set the attribute yourself and do not rely on defaults:

Set-Cookie: session=<opaque-id>; Path=/; Secure; HttpOnly; SameSite=Lax

"Same site" is not "same origin". A sibling subdomain such as blog.example.com is same-site with app.example.com, so a flaw on any sibling can send same-site requests with cookies.

How do testers test for CSRF?#

Testers list the state-changing requests, then check each for a token or equivalent. They follow this order.

1. Inventory. List every request that changes state: forms, fetch calls, GraphQL mutations. Include the ones behind settings pages.
2. Check for a token. Look for a random value in a hidden field, header or cookie.
3. Remove the token. Replay the request with the token missing. Replay with an empty value.
4. Swap the token. Use a token from another test account. Use an old token from the same account.
5. Change the method. If POST is protected, try GET with the same parameters.
6. Check Origin and Referer handling. See if a request with a foreign Origin is accepted.
7. Check cookie attributes. Read SameSite, Secure and HttpOnly on the session cookie.
8. Prove it in a browser (next section).

Test cases#

Why does browser-observed proof matter?#

A browser decides which cookies go with a request, while curl sends whatever you give it. A "missing token" in curl therefore does not prove CSRF. The attack works only if a real browser, on a real cross-site page, sends the session cookie.

For this reason we label CSRF evidence as Browser-observed. We load a test page from a different site in Chromium, signed in as a test account, check whether the state changed, and read the change back. A "success" response alone is not proof.

<form method="POST" action="https://app.harbor-notes.example.com/settings/email">
  <input name="email" value="tester+csrf@example.com">
</form>

POST /settings/email HTTP/1.1
Host: app.harbor-notes.example.com
Origin: https://lab.example.net
Cookie: session=<test-session>
Content-Type: application/x-www-form-urlencoded

email=tester%2Bcsrf%40example.com

What about JSON endpoints?#

JSON APIs that use cookies still need CSRF protection. A cross-site form cannot send application/json, but it can send text/plain with a body that looks like JSON. If the server parses the body without checking the content type, the request goes through.

Test by sending the JSON body with Content-Type: text/plain and application/x-www-form-urlencoded. A safe server returns 415 Unsupported Media Type or checks a token. APIs that need an Authorization: Bearer header are not open to classic CSRF, because the browser does not add that header on its own.

What is login CSRF?#

Login CSRF forces a victim to sign in as the attacker. The victim then uses the app without knowing it, and stores data in the attacker's account. It needs no existing session.

To test it, check whether the login form has a token that is bound to a pre-login session. Submit the login form from a cross-site page with a test account's credentials, in a browser. If the browser ends up signed in as that test account, login CSRF is possible. Also check OAuth: a missing state parameter allows the same attack. See the authentication testing checklist.

How do teams fix CSRF?#

Use several defenses together, because no single one covers every case.

• Synchronizer token or signed double-submit token on every state-changing request, including login. Bind it to the session.
• SameSite=Lax or Strict on the session cookie, set explicitly.
• Verify Origin (and Referer as a fallback) on state-changing requests. Reject foreign values.
• Use only POST, PUT, PATCH or DELETE for changes. Never change state on GET.
• Require a custom header or a JSON content type on APIs, and reject others.
• Re-authenticate for sensitive actions such as email, password and payout changes.

on every non-GET request:
    if request.origin not in allowed_origins: reject 403
    if request.header["X-CSRF-Token"] != session.csrf_token: reject 403

After the fix, ask for a retest in a browser that repeats the same cross-site page and confirms the state does not change. Related reading: the business logic guide and the OWASP Top 10 2025 guide.

What are common false positives in CSRF testing?#

A missing token is not always a vulnerability. Testers check these cases before they report.

• The endpoint needs a bearer header. The browser does not add it for another site, so classic CSRF does not apply.
• The action is harmless. Changing a UI theme has little impact, and severity depends on what the request changes.
• The cookie is not sent. A SameSite=Strict or Lax cookie may not reach the app on a cross-site POST. Prove it in the browser.
• A second factor guards the action. If the request needs a fresh password or code, a forged request fails.
• An Origin check blocks it. The server rejects foreign origins even with no token.

The reverse also happens: a request that fails in a script may work in a browser because of cookies, redirects or Origin rules. So prove CSRF in a real browser and say so in the report. Report only what the browser showed, and put the rest in an open questions section.