Quick answer: CSRF (Cross Site Request Forgery) is a web flaw that tricks the browser of a logged in user into sending a request to a trusted site without the user's knowledge. The attacker does not steal the password; they use the session that is already open. For example, a user with an open banking session who visits an attacker's malicious page may have their browser send a transfer request in the background, because the browser automatically attaches that site's cookies to every request. The core defense is to validate every state changing request with a CSRF token and to restrict cookies with the SameSite attribute.

CSRF has been on the OWASP Top 10 for years and still appears in many applications. The logic is simple: the browser attaches a site's cookies automatically and never asks where the request was triggered from. The attacker abuses that trust. This article explains how CSRF works, which defenses actually help and the common mistakes.

How CSRF works

  1. The user logs into a trusted site (say their bank). A session cookie is created in the browser.
  2. Without logging out, the user opens the attacker's page in another tab.
  3. That page contains a hidden form or image request that sends an action to the target bank.
  4. The browser attaches the session cookie to this request. The server thinks it is valid and authorized and performs the action.

The key point: the attacker cannot read the response, but can trigger the action. So CSRF usually targets state changing operations: money transfer, email change, password reset, settings update. Read only requests are not attractive for CSRF.

CSRF versus XSS

Aspect CSRF XSS
What it does Sends a request as the user Runs code in the victim's browser
Abuses the trust of The site in the user The user in the site
Reads the response No Yes
Main defense CSRF token, SameSite cookie Output encoding, CSP

If XSS exists, CSRF defenses become meaningless because the attacker can run code on the page and read the token. So XSS protection is a precondition for CSRF defense. Think of CSRF as the server blindly trusting the user, and SSRF as the server trusting its own network.

Real defenses against CSRF

1. SameSite cookie attribute

Modern browsers add a SameSite attribute to cookies. With SameSite=Lax or Strict, the browser does not attach the cookie to cross site requests. This blocks most CSRF at the root and is today the first line of defense. Session cookies should be at least Lax, and Strict for sensitive actions.

2. CSRF token

The server embeds an unpredictable, session specific token in every form and expects it on submission. The attacker's page cannot know this token, so the request is rejected. Tokens must be strong random, bound to the session and validated server side.

3. Double submit cookie

The token is sent both in a cookie and in the request body and the server checks they match. It works without server side state, so it is preferred for APIs, but should be combined with SameSite.

4. Origin and Referer check

The server can verify that state changing requests come from its own site by checking the Origin or Referer header. Not sufficient alone, but an extra layer. DSET uses this as a first layer on its own form endpoints.

Common mistakes

  • Changing state with GET. Doing delete or update over GET makes CSRF easy. Every state changing action should be POST, PUT or DELETE and require a token.
  • Token only, no SameSite. They complement each other; modern apps should use both.
  • Accepting a token without validating it. Having a token in the form is not enough; the server must actually check it.
  • Confusing CORS with CSRF. CORS limits reading the response, not sending the request. CORS does not solve CSRF.
  • Keeping a JWT in a cookie without SameSite. Even in token based auth, if a cookie is used, CSRF applies.

Testing and validation

To see whether a flaw is truly exploitable, the web application penetration testing methodology is followed: state changing endpoints are identified, presence and validation of tokens and SameSite settings are checked, and the request is retried with the token removed. DSET reports findings without false positives, with a working proof.

Frequently asked questions

Can CSRF steal my password? Not directly. CSRF does not read your password; it uses your open session to act on your behalf. But if that action changes your email or password, your account can be taken over.

Does the SameSite cookie fully stop CSRF? It reduces it greatly but is not considered sufficient alone. For older browsers, some request types and misconfigurations, use it together with a token.

Do APIs have CSRF? If authentication is cookie based, yes. APIs that only send a token via the Authorization header and use no cookies are naturally resistant.

Does CSRF only happen on websites? Any application that keeps a session via cookies through the browser is at risk. Mobile apps are less affected because they usually use a token header instead of cookies.

Sources

To validate CSRF and other OWASP flaws in your web application with a working proof, contact DSET. From our Ankara Hacettepe Teknokent laboratory we provide penetration testing and secure code review.