# CSRF (Cross-Site Request Forgery)

URL: https://softwaredictionary.org/terms/csrf
Category: Security
Last updated: 2026-09-29
Pronunciation: SEE-surf or see-es-ar-EF

In short: CSRF is an attack that tricks a logged-in user's browser into sending an unwanted request to a trusted site, which treats it as a genuine user action.

## What is CSRF?

Cross-site request forgery abuses the fact that browsers automatically attach cookies to requests. If you are logged in to your bank and visit a malicious page, that page can quietly submit a form to the bank, and your browser will include your session cookie, so the bank sees what looks like a legitimate request from you.

The attacker never sees the response and never learns your password; they only get the site to perform an action, such as changing an email address, transferring money, or deleting data. That is why CSRF targets requests that change state rather than requests that only read data.

The main defenses are anti-CSRF tokens and `SameSite` cookies. A CSRF token is a random, unpredictable value the server embeds in its own forms and checks on every state-changing request, which a third-party site cannot know. Setting session cookies to `SameSite=Lax` or `SameSite=Strict` stops browsers from sending them on most cross-site requests, and checking the `Origin` header adds another layer.

Keeping `GET` requests free of side effects also matters, because links and images can trigger them from anywhere. APIs that authenticate with a token in the `Authorization` header instead of a cookie are generally not exposed to CSRF, since browsers never add that header automatically. CSRF differs from XSS: CSRF sends a forged request from another site, while XSS runs attacker code inside the target site itself.

## Key takeaways

- CSRF exploits cookies that browsers send automatically.
- It targets state-changing actions, not reading data.
- Anti-CSRF tokens prove a request came from the real site's own pages.
- `SameSite` cookies block most cross-site cookie sending.
- `GET` requests should never change data.

## Example: Vulnerable vs. protected form handler (Express)

```javascript
// Vulnerable: any website can submit this form on the user's behalf
app.post("/email", requireLogin, (req, res) => {
  updateEmail(req.user, req.body.email);
  res.sendStatus(204);
});

// Protected: require a secret token that only our own form contains
app.post("/email", requireLogin, (req, res) => {
  if (req.body.csrfToken !== req.session.csrfToken) {
    return res.status(403).send("Invalid CSRF token");
  }
  updateEmail(req.user, req.body.email);
  res.sendStatus(204);
});
```

## Frequently asked questions

**What is the difference between CSRF and XSS?**

CSRF makes a user's browser send a request to a trusted site from a different, malicious site, while XSS injects script that runs inside the trusted site itself. XSS is usually more dangerous, because injected script can bypass most CSRF protections.

**Do SameSite cookies prevent CSRF?**

`SameSite=Lax` or `SameSite=Strict` blocks most CSRF attacks by not sending cookies on cross-site requests, and some browsers treat cookies without the attribute as `Lax` by default. It is still recommended to combine it with CSRF tokens or `Origin` checks for defense in depth.

**Do JWT-based APIs need CSRF protection?**

If the token is stored in a cookie, yes, because the browser sends it automatically. If the token is sent manually in an `Authorization` header, CSRF is generally not a concern, but the token must then be protected from XSS.

## Sources

- [OWASP: Cross Site Request Forgery (CSRF)](https://community.owasp.org/attacks/csrf)
- [OWASP Cheat Sheet: Cross-Site Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)

---

Software Dictionary: https://softwaredictionary.org/ · https://softwaredictionary.org/llms.txt