What is CSRF?

Security

The short answer

CSRF is an attack where a malicious website tricks a user's browser into making a request to another site where the user is already logged in. The browser automatically sends cookies with the request, so the target site thinks it is a legitimate action from the user. The attacker cannot see the response, but the action (like transferring money or changing a password) still happens.

How it works

Let's say you are logged into your bank at bank.com. Your browser has a session cookie for that site. Now you visit a malicious page that has this hidden form:

<form
  action="https://bank.com/transfer"
  method="POST"
  id="evil-form"
>
  <input type="hidden" name="to" value="attacker-account" />
  <input type="hidden" name="amount" value="10000" />
</form>
<script>
  document.getElementById('evil-form').submit();
</script>

When this page loads, the form submits automatically. Your browser sends the request to bank.com and includes your session cookie because you are logged in. The bank sees a valid session and processes the transfer. You never clicked anything — the malicious page did it for you.

Why cookies are the problem

The key issue is that browsers automatically attach cookies to every request to a domain, regardless of where the request came from. The bank cannot tell the difference between a request from its own page and a request from the attacker's page — both have the same session cookie.

How to prevent CSRF

1. CSRF tokens (most common)

The server generates a unique, random token and includes it in every form. When the form is submitted, the server checks if the token matches. The attacker cannot get this token because they cannot read the page content from another domain (same-origin policy).

<form action="/transfer" method="POST">
  <input
    type="hidden"
    name="_csrf"
    value="random-unique-token"
  />
  <input type="text" name="amount" />
  <button type="submit">Transfer</button>
</form>

2. SameSite cookie attribute

Modern browsers support the SameSite attribute on cookies:

Set-Cookie: session=abc123; SameSite=Strict
  • SameSite=Strict — Cookie is never sent with cross-site requests. Most secure but can affect user experience (clicking a link to a site will not have the cookie).
  • SameSite=Lax — Cookie is sent with top-level navigation (clicking links) but not with form submissions from other sites. Good balance of security and usability.
  • SameSite=None — Cookie is always sent (must also use Secure flag). This is the old behavior.

3. Check the Origin / Referer header

The server can check where the request came from by looking at the Origin or Referer header. If it is not from the same domain, reject the request.

4. Use custom headers with AJAX

For API calls, require a custom header like X-Requested-With. Browsers do not allow cross-site requests to set custom headers without a CORS preflight, which the server can reject.

Common Pitfalls

A common misconception is that CSRF only affects forms. Any state-changing request (POST, PUT, DELETE) can be vulnerable. GET requests should never change state — this is why "GET should be safe and idempotent" is a web standard. If your GET endpoint does something like /delete-account?id=123, it is vulnerable to CSRF through a simple image tag: <img src="https://example.com/delete-account?id=123" />.

Interview Tip

When explaining CSRF, walk through the attack step by step — the user is logged in, visits a malicious site, the browser sends cookies automatically. Then cover the defenses: CSRF tokens, SameSite cookies, and Origin header checks. Mentioning SameSite cookies shows you are up to date with modern browser security features.

Why interviewers ask this

CSRF is one of the top web security vulnerabilities. Interviewers want to see if you understand how cookies work across sites, why automatic cookie sending is dangerous, and how to protect against it. This is especially important for frontend developers who build forms and API integrations.

Table of Contents