---
{
  "title": "Cross-site request forgery",
  "summary": "A browser may send ambient credentials with an unintended request.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: Web Security Testing Guide",
      "url": "https://owasp.org/www-project-web-security-testing-guide/"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

CSRF exploits a browser’s ability to send authenticated requests to a service while the user interacts with another site. The risk depends on credentials, request design, and browser behavior. Defenses can include anti-CSRF tokens, appropriate SameSite cookies, origin checks, and avoiding state changes through unsafe request patterns. XSS can undermine some protections, so defenses must be considered together. Authentication alone does not prove that the user intended the action.

## In practice

An application requires a validated anti-CSRF token before changing an account setting through a browser session.

## A common misunderstanding

An authenticated request is not necessarily an intentionally initiated request.

## Check your understanding

Why are read-only and state-changing operations treated differently?

**Think it through:** Unintended state changes can cause harm even when the browser automatically supplies valid credentials.

## The browser can supply credentials automatically

A fictional account service lets a signed-in user change a delivery address. If the browser automatically attaches a session cookie to a request, the server needs a separate way to distinguish an intended action from a request induced by another page. The attack does not require learning the victim's password; it takes advantage of the browser's existing authenticated relationship.

The precise risk depends on how the request is constructed and which credentials the browser sends. A browser cookie, an authorization header added by trusted application code, and a token placed in a form do not have identical behavior. Avoid treating every API as equally vulnerable or assuming that JSON alone removes the issue. Review the actual browser flow and accepted content types.

CSRF tokens should be validated by the server according to the application's chosen pattern. SameSite cookies and origin checks can add useful constraints, but their behavior must fit legitimate cross-site workflows. A login or payment integration may deliberately involve navigation between sites. Security review needs to explain those exceptions rather than disabling protection broadly when a workflow breaks.

## Reason about intent

Draw two requests for the address change: one initiated through the service's own form and one induced from an unrelated fictional page. Identify which fields the browser adds automatically and which proof is available only to the legitimate flow. This paper exercise makes the missing assurance visible without targeting an actual user.

Sensitive operations may also need confirmation or renewed authentication. Those controls protect more than CSRF, but they should not replace correct request validation. Include an expired session, a missing token, and a mismatched origin in authorized regression checks. Explain expected failures clearly so future interface changes preserve the protection rather than accidentally bypassing it.

## Keep exploring

- [[sessions-and-cookies]]
- [[http]]
- [[xss]]