Cross-Site Request Forgery (CSRF)

5.8. Cross-Site Request Forgery (CSRF)#

Cross-Site Request Forgery (CSRF) is an attack where an attacker tricks a user into submitting unauthorised requests to websites where the user is logged in.

5.8.1. Recommended Video#

5.8.2. How CSRF Works#

A user logs in to a website, such as a banking application, and their browser stores a session cookie.
The user visits a separate, malicious website or clicks a deceptive link.
The malicious site or link causes the user’s browser to send a request to the banking application (for example, transferring money).
Because the user’s browser includes the valid session cookie, the banking application processes the request as though it were legitimate.

5.8.3. Example#

Suppose you run a website where users can posts short messages onto a public feed. To post messages, logged in users complete a form on your site that sends a POST request to your server.

An attacker could create a website that:

looks the same as yours (page styling and similar domain name)
contains a hidden form to post to your site
tries to submit the form, using the session cookie of the visiting user

With this technique, an attacker could post as any logged in user that visits the malicious site that they set up.

5.8.4. Preventing CSRF#

There are several techniques for preventing CSRF attacks.

CSRF Tokens

A CSRF token is a unique identifier that the webserver inserts onto its own pages. This token is attached to any forms that are submitted from these pages.

If the web server receives a request with form data it checks for the presence and correctness of the token. If the token is missing or incorrect then the request is rejected.

SameSite Cookies

By setting cookies with SameSite=Lax or SameSite=Strict, browsers will not include those cookies on cross-site requests. In other words such SameSite cookies are only sent when the browser is on a page that created them.

Browser-Supported Request Checks

Modern browsers send extra request headers that can help servers decide whether a request came from the same site as the application.

One example is the Sec-Fetch-Site header, which is part of Fetch Metadata. A server can reject state-changing requests when this header says the request is cross-site. When this header is not available, some applications also check the Origin or Referer header as a fallback.

These browser-supported checks can reduce the need for hidden form fields in some modern applications, but they still need careful implementation. In practice, developers should use the CSRF protection provided by their web framework where possible. If an application relies on Fetch Metadata or origin checks, it should be tested with the browsers and clients it supports.

5.8.5. Glossary#

CSRF#: Cross-Site Request Forgery. An attack where an attacker tricks a user into submitting unauthorised requests to a website where the user is logged in.
CSRF token#: A unique identifier inserted into a website’s own pages and checked when forms are submitted.
SameSite cookie#: A cookie configured so browsers do not include it on some or all cross-site requests.
Fetch Metadata#: Browser-provided request headers that describe how a request was made, including whether it came from the same origin, same site, or a different site.