Understanding CSRF: How Websites Get Tricked Into Trusting You

Introduction

Modern websites remember who you are using sessions and cookies. That's what keeps you logged in without entering your password again and again.

But this convenience comes with a hidden risk.

What if a malicious website could force your browser to perform actions on another site… without you knowing?

That's exactly what a CSRF (Cross-Site Request Forgery) attack does.

What is CSRF?

A CSRF attack tricks your browser into sending a request to a website where you are already authenticated.

The key idea is simple:

• You are logged into a trusted site (like a bank or social media)
• You visit a malicious site
• That site silently sends a request using your credentials

Since your browser automatically includes cookies, the target website thinks you made the request.

As described in the reference material, this works because authentication is stored in the browser (usually via cookies), which are automatically attached to requests.

Why CSRF Works

Web apps rely heavily on cookies for authentication.

Here's the problem:

• Cookies are automatically sent with every request to the same domain
• Websites often don't verify where the request came from
• So, a malicious site can "borrow" your session

That's the core vulnerability.

A Simple Example

Imagine this flow:

1. You log into your bank account
2. You don't log out
3. You open another random website
4. That website silently triggers this request:

https://bank.com/transfer?to=attacker&amount=5000

Your browser sends this request with your session cookie.

The bank processes it like a normal request.

You just lost ₹5000… without clicking anything.

Real Attack Example (GET-based CSRF)

One classic way CSRF works is through something as harmless as an image.

A malicious site could include:

<img src="https://bank.com/transfer?to=attacker&amount=5000" />

When your browser loads this page:

• It tries to "load the image"
• It sends a GET request to the bank
• Your cookies go along with it
• The transaction happens

This works because browsers automatically load resources like images and include cookies in those requests.

POST-Based CSRF (More Realistic)

Modern apps use POST requests for actions like payments.

Attackers handle this using hidden forms:

<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="to" value="attacker" />
  <input type="hidden" name="amount" value="5000" />
</form>
 
<script>
  document.forms[0].submit()
</script>

This runs silently when you visit the page.

You don't see anything. But the request still happens.

Key Insight

CSRF is dangerous because:

• It doesn't steal your password
• It doesn't break authentication
• It abuses existing trust

The server trusts your browser… and that's exactly what attackers exploit.

How to Prevent CSRF

1. CSRF Tokens (Most Important)

Each request includes a random, secret token.

• Generated by the server
• Sent with forms or headers
• Verified before processing

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

2. SameSite Cookies

Cookies can be restricted using:

• SameSite=Strict → only sent from same site
• SameSite=Lax → sent for safe requests

This prevents cookies from being sent during cross-site requests.

3. Avoid Using GET for Sensitive Actions

Never use GET for things like:

• Money transfers
• Password changes
• Account updates

GET should only fetch data, not modify it.

4. Check Origin / Referer Headers

Servers can verify where the request came from.

If it's not your domain → reject it.

One Real-World Lesson

A real vulnerability once allowed users to disconnect their accounts just by visiting a URL.

No confirmation. No token.

Just:

GET /disconnect-account

Attackers embedded this in a malicious page, and users unknowingly triggered it.

Lesson: If a request changes data, it must never be blindly trusted.

Final Thoughts

CSRF is subtle but powerful.

It doesn't rely on breaking systems — it relies on misusing trust between your browser and a website.

If you're building web apps:

• Always use CSRF tokens
• Be careful with cookies
• Never trust requests blindly

If you understand CSRF deeply, you're already thinking like a security engineer.