What is Cross-Site Request Forgery (CSRF)?

Definition

Cross-site request forgery (CSRF) is an attack that tricks an authenticated user into submitting a request to a web application they are logged into, without their knowledge or intent. Because the browser automatically includes session cookies with every request to a domain, the forged request carries the victim's credentials and the server has no way to distinguish it from a legitimate action.

CSRF exploits the trust a web application has in its users' browsers. The attack does not steal credentials — it uses existing authentication to perform unauthorized actions on behalf of the victim.

How CSRF Works

The attack follows a simple pattern:

1. The victim is authenticated to a target application (their browser holds a valid session cookie).
2. The victim visits a malicious page (via a phishing link, a compromised ad, or an attacker-controlled site).
3. The malicious page contains a hidden form or image tag targeting the vulnerable application.
4. The browser automatically submits the request, including the session cookie.
5. The target application processes the request as if the authenticated user initiated it.

Classic examples: transferring funds from a banking application, changing an email address, adding an admin user, or deleting data — any state-changing operation accessible to the victim.

CSRF vs. XSS

Prevention

CSRF tokens

The application generates a unique, unpredictable token per session (or per form submission) and includes it as a hidden field in every state-changing form. On submission, the server validates the token. An attacker on a different origin cannot read the token and therefore cannot forge a valid request.

SameSite cookie attribute

Setting cookies with SameSite=Strict or SameSite=Lax prevents browsers from sending them with cross-site requests. SameSite=Strict blocks the cookie on all cross-origin requests; Lax blocks it on cross-origin non-safe methods (POST, PUT, DELETE). This is now the most effective and easiest-to-implement defense.

Origin and Referer header validation

The server checks that the Origin or Referer header of state-changing requests matches the expected application origin. This is a weaker defense than tokens because headers can be absent, but it adds a layer of defense-in-depth.

Custom request headers

Requiring a custom header (X-Requested-With: XMLHttpRequest) that cannot be set by cross-origin forms. Browsers enforce the same-origin policy on custom headers in cross-origin requests. Only valid for AJAX requests, not form submissions.

CSRF and Autonomous Code Governance

Hydra detects missing CSRF protection on state-changing endpoints by analyzing route definitions, HTTP method usage, and the presence of CSRF token validation middleware. For frameworks with built-in CSRF protection (Rails, Django, Laravel), Hydra identifies endpoints where protection has been explicitly disabled or bypassed. Fixes add the appropriate token validation or SameSite cookie configuration for the framework in use.