🛡️ Cross-Site Request Forgery (CSRF): Understanding the Attack, SameSite Cookies & Modern Defenses

Imagine you're logged into your online banking account. After checking your balance, you leave the tab open and continue browsing other websites. A few minutes later, you visit what appears to be an ordinary webpage. Without asking for your password again or displaying any warning, your browser silently sends a request to your bank.

The request includes your authenticated session cookie, and because the bank recognizes that cookie, it processes the request as if you initiated it.

This is the idea behind Cross-Site Request Forgery (CSRF).

Unlike many other web attacks, CSRF doesn't steal your password or exploit a software vulnerability on your computer. Instead, it takes advantage of the trust a website places in your authenticated browser session.

In this article, we'll explore how CSRF works, why browsers automatically send cookies, how SameSite cookies help reduce the risk, and why modern web applications still rely on multiple layers of defense to protect users.

What is CSRF?

Cross-Site Request Forgery (CSRF) is a web security attack in which an attacker tricks a victim's browser into sending an unwanted request to a website where the victim is already authenticated.

If the request performs a sensitive action such as changing an email address, transferring money, or updating account settings the server may process it because it recognizes the victim's valid session cookie.

The key point is that the attacker doesn't need to know your password. Instead, they abuse the trust that already exists between your browser and the website.

A Simple Example

Imagine Alice is logged into her online banking account. The bank identifies Alice using a session cookie stored in her browser.

While still logged in, Alice receives a link through email or social media that leads to a malicious webpage.

Behind the scenes, that webpage automatically submits a request like:

"Transfer $10,000 to another account."

Since Alice's browser automatically includes her authenticated session cookie, the bank receives what appears to be a legitimate request from a logged-in user.

If the application doesn't verify that the request genuinely originated from Alice, the transaction could be processed successfully.

How Does a CSRF Attack Work?

A typical CSRF attack follows these steps:

1. The victim logs into a trusted website.

The server authenticates the user and stores a session cookie in the browser.

↓

2. The victim remains logged in.

The browser keeps the session active and automatically includes the cookie whenever requests are sent to that website.

↓

3. The victim visits a malicious webpage.

The attacker tricks the victim into opening a specially crafted page through phishing emails, advertisements, or social media links.

↓

4. A hidden request is sent.

The malicious page silently submits a request to the trusted website.

↓

Since the browser believes the request is intended for the trusted website, it attaches the authentication cookie.

↓

6. The server processes the request.

Without additional validation, the server may assume the request came from the legitimate user.

Why Does the Browser Send Cookies Automatically?

This is the most important concept to understand. Browsers are designed to automatically send cookies whenever a request is made to the domain that originally created them. This behavior improves usability because users don't need to log in every time they click a new page or submit a form.

For example, after logging into your favorite shopping website, every request you make includes your session cookie automatically. That's why your shopping cart, account details, and order history remain available without requiring repeated authentication.

However, this same convenience can become dangerous if an attacker manages to trick the browser into sending an unwanted request.

The browser cannot always determine whether the request was genuinely initiated by the user or by a malicious webpage.

SameSite Cookies

To reduce the risk of CSRF attacks, modern browsers support the SameSite cookie attribute. This attribute tells the browser when cookies should be included in cross-site requests.

There are three possible values.

SameSite=Strict

This provides the strongest protection. The browser sends the cookie only when the request originates from the same website.

Cross-site requests won't include the cookie, making CSRF attacks significantly more difficult.

The trade-off is usability. Some legitimate cross-site navigation scenarios may require users to authenticate again.

SameSite=Lax

This is a balanced approach and is commonly used by many websites.

Cookies are still withheld from most cross-site requests, but they are included during certain top-level navigations with safe HTTP methods (GET,HEAD and OPTIONS) initiated by the user, such as clicking a normal hyperlink.

This offers better usability while still providing meaningful protection against many CSRF attacks.

SameSite=None

This instructs the browser to send cookies with cross-site requests.

Because this reduces CSRF protection, browsers require the cookie to also include the Secure attribute, ensuring it is transmitted only over HTTPS connections.

This configuration is typically used only when cross-site cookies are genuinely required, such as Single Sign-On (SSO), third-party authentication providers, or embedded services.

The SameSite Lax+POST Compatibility Exception

Modern Chromium-based browsers introduced an important compatibility feature. If a website sets a cookie without explicitly specifying a SameSite attribute, browsers generally treat it as SameSite=Lax.

However, for a short period after the cookie is created, browsers apply a temporary Lax+POST compatibility exception. During this brief window, some top-level cross-site POST requests may still include the newly created cookie.

This behavior exists to maintain compatibility with older websites during the transition to stricter cookie policies.

Although this window is limited, security professionals should be aware of it because it has been demonstrated in practical security labs and highlights why SameSite cookies alone should never be considered a complete CSRF defense.

Why Same-Origin Policy (SOP) & CORS Alone Don't Prevent CSRF

One of the most common misconceptions in web security is that Same-Origin Policy (SOP) or Cross-Origin Resource Sharing (CORS) automatically prevent CSRF attacks.

While both are important browser security mechanisms, they solve different problems.

What is Same-Origin Policy (SOP)?

The Same-Origin Policy prevents a website from reading sensitive data from another origin without permission.

For example, if an attacker creates a malicious website, their JavaScript cannot simply read your online banking account details because the browser blocks access to cross-origin responses.

However, SOP does not generally prevent the browser from sending many cross-site requests. If the browser already has a valid session cookie for the target website, it may still include that cookie when making certain requests.

In other words:-

— SOP protects the confidentiality of data.

— SOP does not replace CSRF protection.

What About CORS?

Cross-Origin Resource Sharing (CORS) allows a server to decide whether cross-origin JavaScript should be allowed to access its responses. Many people mistakenly believe that enabling CORS automatically prevents CSRF.

That's not true.

CORS mainly controls whether JavaScript can read responses from another origin. Traditional CSRF attacks often rely on browser behavior such as HTML forms or top-level navigation rather than reading the response.

This is why security frameworks still implement dedicated CSRF protections even when CORS is configured correctly.

How Developers Prevent CSRF

Modern web applications don't rely on a single security mechanism. Instead, they use multiple layers of protection.

1. CSRF Tokens

A CSRF token is a unique, unpredictable value generated by the server and included with sensitive requests. When the request reaches the server, the token is validated.

If the token is missing or invalid, the request is rejected.

Because attackers cannot easily obtain or guess this token, forged requests become much more difficult to execute.

2. SameSite Cookies

As discussed earlier, the SameSite attribute instructs browsers when cookies should be included in cross-site requests.

Using SameSite=Strict or SameSite=Lax can significantly reduce the risk of many CSRF attacks. However, SameSite should be considered one layer of defense, not the only one.

3. Origin & Referer Validation

Browsers often include the Origin or Referer header with requests. Servers can inspect these headers to verify that requests originate from trusted websites.

If a sensitive request arrives from an unexpected origin, the server can reject it before performing any action.

4. CAPTCHA for High-Risk Actions

CAPTCHA is not a primary CSRF defense, but it can provide an additional layer of protection for sensitive operations such as:

Password changes
Money transfers
Account recovery
Administrative actions

It helps ensure that a real user is performing the action rather than an automated or malicious request.

5. Defense in Depth

No single security control can stop every attack. Modern applications combine multiple defenses, including:-

CSRF Tokens
SameSite Cookies
Origin & Referer Validation
Secure Session Management
CAPTCHA for sensitive actions
Regular security testing

This layered approach is known as Defense in Depth and is considered a security best practice.

What Can Users Do to Stay Safe?

While developers are responsible for implementing secure applications, users can also reduce their exposure to CSRF attacks by following good security practices.

✅ Be cautious with unexpected links

Avoid clicking suspicious links in emails, messages, or social media, especially when you're logged into sensitive websites.

✅ Log out after using sensitive services

Logging out of online banking, government portals, or administrative dashboards reduces the risk of an active authenticated session being abused.

✅ Keep your browser updated

Modern browsers continuously improve security features such as cookie handling and browser protections.

✅ Verify unexpected actions

If a website suddenly asks you to confirm a payment or change account settings without your request, pause and verify the action.

✅ Enable Multi-Factor Authentication (MFA)

Although MFA does not directly prevent CSRF, it strengthens overall account security and helps protect against many other forms of account compromise.

Want to Practice CSRF Hands-On?

I highly recommend completing the free CSRF room on TryHackMe:

🔗 https://tryhackme.com/room/csrfV2

Conclusion

Cross-Site Request Forgery (CSRF) highlights how attackers can exploit trusted browser sessions rather than stealing credentials. By combining security measures like CSRF tokens, SameSite cookies, and request validation, developers can effectively reduce this risk. Understanding these concepts is an important step toward building and using more secure web applications.

🔗 Connect With Me

🤝 LinkedIn

Contents