Cross-Site Request Forgery (CSRF)

Tricking authenticated users into performing unwanted actions

Introduction

Modern web applications rely heavily on user authentication and authenticated sessions.

Once a user logs into a website, the application typically creates a session that allows the user to perform actions without repeatedly entering their credentials. Session information is often stored in a cookie on the users device and is passed between user and server each time a new page is requested.

For example, after logging into an online banking application, a user might be able to:

View account information
Transfer money
Change personal details
Add beneficiaries
Change account settings

The application knows that requests are coming from an authenticated user because the user’s browser automatically includes the relevant session cookie or authentication credentials.

This creates an important security problem – What if an attacker can cause the victim’s browser to send a legitimate request to the application without the victim intentionally requesting it?

This is the fundamental concept behind a Cross-Site Request Forgery (CSRF) attack.

CSRF can allow an attacker to abuse a victim’s existing authenticated session to perform actions on their behalf. The key concept here is that The request comes from the victim’s browser — but the victim did not intentionally make the request.

What is CSRF?

A Cross-Site Request Forgery (CSRF) attack is one where an attacker causes a user’s browser to send an unauthorised or unintended request to a web application where the victim is already authenticated. The attack takes advantage of the fact that browsers may automatically include authentication information with requests.

If successful, the web application may incorrectly assume that the authenticated user intentionally made the request and divulge information unwittingly to the attacker

The Core CSRF Problem

Consider a legitimate application such as bank.example.

The victim logs in, and the server sends a session cookie to the browser (session=ABC123)

The victim is now authenticated.

The attacker now creates malicious content that causes the victim’s browser to make a request to the banking application. The browser may automatically include session=ABC123 as part of that request

Now the banking application receives the Authenticated Request and may process it

The attacker has therefore abused the victim’s authenticated session without needing to know the victim’s password.

CSRF Attack Scenario

Imagine a web application contains an account-change function. The legitimate request might conceptually be:

Change Email Address -> HTTP POST /change-email -> email=newaddress@example.com

The victim is already authenticated to the server due to the fact that they have already logged into their account

If an attacker attempts to cause the victim’s browser to submit the same request, the resulting flow becomes

Attacker-controlled page -> Victim’s browser -> Authenticated web application ->Account change ->HTTP POST /change-email -> email=newaddress@attacker.com

The attacker has not necessarily stolen the victim’s session cookie, Instead, they have caused the browser to use it automatically.

Why CSRF Works

CSRF relies on a fundamental difference between Authentication and Intent

The server may be able to determine “This request came from an authenticated user.”

But it may not be able to determine “This request was deliberately initiated by that user.”

This distinction is critical – A valid session proves who is making the request; It does not necessarily prove why the request was made.

CSRF does not require stealing a users cookie

This is one of the most important concepts in that CSRF is fundamentally different from session theft.

In a session theft attack, the attacker obtains session credentials and then uses those credentials to obtain access

With CSRF, the victim already has session credentials. The attacker tricks the user to send an authenticated request which the application processes

The attacker is therefore abusing the victim’s authenticated browser rather than necessarily obtaining the authentication credential themselves.

Example case – Account Changes

CSRF can become particularly serious when applications allow sensitive account changes without requiring additional verification.

Potential targets could include:

Password changes
Email changes
Profile changes
Security settings
API key creation
Account configuration
Payment information
User permissions

The impact depends on what actions the vulnerable application allows.

Example case – Financial Transactions

A particularly serious scenario involves financial applications. Imagine a banking application that allows an authenticated user to initiate a monetary transfer.

A vulnerable application could potentially process an attacker-controlled request as if it had been deliberately submitted by the victim.

This is why high-value actions require strong CSRF protections and often additional authentication controls.

CSRF and HTTP GET Requests

HTTP GET requests are normally intended to retrieve information from a service rather than change state.

For example, GET /account might retrieve account information from the server

A dangerous situation occurs when applications use GET requests to perform state-changing operations.

For example, GET /delete-account would be problematic because browsers can generate GET requests in many ways.

Applications should therefore follow an important principle – State-changing operations should not be performed using GET requests.

Operations that change data should generally use methods such as POST, PUT, or DELETE with appropriate security controls.

However, simply changing GET to POST does not automatically prevent CSRF – Additional protection is still required.

CSRF Tokens

One of the most common CSRF defences is the CSRF token.

A CSRF token is a unique, unpredictable value associated with the user’s session. The application includes the token in legitimate forms or requests.

For example a legitimate Request could look something like:

POST /change-emailemail=user@example.comcsrf_token=8f91c2...

The server verifies the token before processing the request. If an attacker attempts to forge the request, they would, in most cases not know the valid token, and the request is therefore rejected.

What makes a good CSRF token?

A CSRF token should generally be:

Unpredictable
Cryptographically strong
Difficult to guess
Associated with the user’s session
Validated by the server
Protected from unauthorised disclosure

A predictable token can significantly weaken the protection.

The objective here is to ensure that an attacker cannot simply construct a valid request.

Synchroniser Token Pattern

The Synchroniser Token Pattern is a common CSRF defence. In this technique, the server maintains a token associated with the user’s session.

For example: Session = ABC123 -> CSRF Token = 9f7a2c...

When the user submits a state-changing request, the application checks the supplied token against the expected value.

If the token and session data validate, then the action is processed, if not, the action is refused.

Double-Submit Cookie Pattern

Another CSRF defence is the Double-Submit Cookie pattern. Here, the application provides a CSRF token through a cookie. The client then submits the same token through another request parameter or header, and the server compares the two values.

SameSite Cookies

Modern browsers provide another important defence through the SameSite cookie attribute.

SameSite controls when cookies are included with requests originating from different sites. Common settings for SameSite include:

Strict
Lax
None

For example:

SameSite=Strict: provides strong restrictions on cross-site cookie transmission.

SameSite=Lax : provides a more permissive model while still offering protection against many cross-site requests.

SameSite=None: allows cross-site cookie usage but requires additional configuration, including Secure in modern browsers.

SameSite should be treated as an important defence layer, rather than the only CSRF protection for sensitive applications.

Origin Header

Applications can also examine the Origin HTTP request header. This header can indicate the origin from which a request was made.

For example: Origin: https://legitimate.example

The server compares the supplied origin against an allow-list of trusted origins. If a request originates from an unexpected site, it can be rejected.

This provides another mechanism for distinguishing legitimate requests from potentially forged cross-origin requests.

Referer Header

The Referer HTTP header can sometimes provide additional information about where a request originated. An application may use it as part of its request-validation strategy.

However, relying exclusively on Referer checking can be problematic because headers can be absent or affected by browser privacy controls and security policies.

It should therefore generally be treated as a supplementary control rather than the sole defence.

CSRF vs XSS

CSRF and Cross-Site Scripting (XSS) are often confused because both involve malicious web content.

However, they exploit different weaknesses.

Feature	CSRF	XSS
Primary target	User’s authenticated session	Web application’s handling of content
Main objective	Cause unintended actions	Execute attacker-controlled script
Requires victim authentication?	Often	Not necessarily
Cookie theft	Not normally required	Potentially
Main defence	CSRF tokens, SameSite, Origin checks	Output encoding, sanitisation, CSP
Attacker’s code executes in target origin?	No	Yes

The distinction is important.

CSRF abuses the victim’s browser to send a request.
XSS causes attacker-controlled script to execute within the application’s security context.

XSS can defeat some CSRF protections

A successful XSS vulnerability can make CSRF protections much less effective.

For example, If attacker-controlled JavaScript is executing within the legitimate application’s origin, it may be able to interact with the application’s forms and requests in ways that a separate malicious website cannot.

This is why preventing XSS remains an important part of defending web applications against CSRF-related attacks.

CSRF in modern web applications

CSRF remains relevant to applications that use browser-based authentication. It is particularly important where:

Authentication relies on cookies
Sessions remain active for long periods
Sensitive actions do not require reauthentication
State-changing requests lack CSRF protection
Cross-origin requests are insufficiently restricted

Modern frameworks often provide built-in CSRF protection, but developers still need to configure and use those protections correctly.

CSRF in Single-Page Applications

Modern Single-Page Applications (SPAs) can use authentication architectures that reduce or change traditional CSRF risks.

For example, applications may use:

Bearer tokens
API authentication headers
SameSite cookies
CSRF tokens
Backend-for-Frontend architectures

The exact security model depends on how authentication credentials are stored and transmitted, but the important principle remains – Understand how the browser authenticates each request.

If authentication credentials are automatically attached to cross-site requests, CSRF remains an important consideration.

CSRF and APIs

Not every API is vulnerable to traditional CSRF – An API using an authentication mechanism that requires an attacker to explicitly provide a credential in an HTTP header may be less susceptible to traditional browser-based CSRF.

An attacker generally cannot cause the victim’s browser to automatically add an arbitrary Authorization header to a cross-origin request, however, API authentication design must still be assessed carefully.

Poorly designed APIs can introduce other forms of cross-origin abuse.

CSRF and CORS

Cross-Origin Resource Sharing (CORS) is another concept that is frequently confused with CSRF.

CORS controls whether browser-based JavaScript can access responses from another origin.
CSRF concerns whether an attacker can cause a request to be sent.

These are different security mechanisms.

CORS controls “Can this script read the response?”

concerns “Can this request be made in the first place, and will the server accept it?”

A permissive CORS configuration can introduce additional security problems, but CORS should not be considered a replacement for CSRF protection.

CSRF and Authentication

Strong authentication can reduce the impact of CSRF, but it does not automatically eliminate the vulnerability. For particularly sensitive actions, applications can require step-up authentication.

Additional verification might involve:

Re-entering a password
Multi-factor authentication
Passkeys
Transaction confirmation

This creates another security boundary around high-value actions.

CSRF and Multi-Factor Authentication

Multi-factor authentication protects the authentication process, however, once a user is authenticated, CSRF can potentially abuse the resulting session.

MFA therefore should not be considered a replacement for CSRF protection – The controls address different parts of the attack chain.

Detecting CSRF attacks

CSRF can be difficult to detect from the server side because the malicious request may look like a legitimate authenticated request.

Security teams should therefore look for unusual patterns such as:

Unexpected state-changing requests
Requests originating from unexpected origins
Missing or invalid CSRF tokens
Unusual Referer or Origin values
Account changes that the user did not initiate
Unexpected password changes
Unexpected email changes
Unusual financial transactions
Changes immediately following visits to suspicious sites

Application logs are particularly important.

Preventing CSRF

Organisations and developers should implement multiple layers of protection:

Use CSRF tokens – Require unpredictable tokens for state-changing requests.
Use SameSite cookies – Configure authentication cookies appropriately.
Validate Origin – Where appropriate, verify that requests originate from trusted origins.
Use secure HTTP methods – Do not use GET requests for state-changing operations.
Require reauthentication – Use additional authentication for highly sensitive actions.
Use secure application frameworks – Take advantage of built-in CSRF protections rather than implementing security mechanisms unnecessarily from scratch.
Protect against XSS – XSS can undermine many application security controls.
Monitor sensitive actions – Log and monitor account and configuration changes.

CSRF Prevention Checklist

Organisations should consider:

Using unpredictable CSRF tokens.
Validation of CSRF tokens server-side.
Configure SameSite cookies appropriately.
Using Secure and HttpOnly cookie attributes where appropriate.
Validation of Origin headers for sensitive requests.
NOT using GET for state-changing operations.
Requiring additional authentication for high-value actions.
Protecting against XSS.
Configuring CORS securely.
Keeping web frameworks updated.
Monitoring for unusual account changes.
Logging sensitive state-changing requests.
Detecting failed CSRF-token validation.
Reviewing authentication architecture.
Testing applications for CSRF vulnerabilities.

CSRF Testing

Security professionals can assess applications for CSRF vulnerabilities by examining state-changing functionality. Important areas to test include:

Account modification
Password changes
Email changes
Payment actions
User creation
Permission changes
API key creation
Administrative functions
Configuration changes
Data deletion

The objective is to determine whether an attacker can cause a victim’s authenticated browser to perform an action without the application verifying that the request was intentionally generated by the legitimate application.

Conclusion

Cross-Site Request Forgery (CSRF) is a web application attack that abuses the relationship between a user’s browser, authentication session, and a web server.

The attacker does not necessarily need to steal the victim’s credentials – Instead, they attempt to cause the victim’s browser to send a request that the target application interprets as legitimate.

Effective protection requires multiple layers.

CSRF tokens, SameSite cookies, Origin validation, secure application design, strong authentication, XSS prevention, and careful monitoring all contribute to reducing the risk.

The key lesson is simple – A valid authentication session does not prove that a request was intentionally made by the user.

Modern web applications must therefore protect not only who is making a request, but also whether the request was legitimately initiated.

The browser may be authenticated — but that does not mean every request it sends should be trusted.