Modern web applications rely heavily on authenticated user sessions. Once a user logs in, their browser often stores cookies or session tokens that are automatically sent with future requests. This creates convenience—but also introduces a major security risk known as a CSRF attack.

CSRF stands for: Cross-Site Request Forgery

It is one of the classic web security vulnerabilities and remains relevant whenever browser-based authentication is used.

This article explains:

• What CSRF attacks are
• Why they happen
• How attackers exploit them
• Real examples
• How frameworks like Django defend against them
• Best prevention strategies

What Is a CSRF Attack?

A CSRF attack occurs when a malicious website tricks a user’s browser into sending an unwanted request to another website where the user is already authenticated.

The key idea:

1. The victim is logged in to a trusted site
2. Their browser automatically sends cookies
3. The attacker causes the browser to submit a forged request

The trusted site may believe the request came intentionally from the user.

Why CSRF Exists

Browsers are designed to automatically include cookies with matching domains.

Example:

User logs into:

bank.com

Browser stores:

sessionid=abc123

Later, any request to bank.com may automatically include that cookie.

That convenience enables sessions—but also enables CSRF if requests are not verified.

A Simple CSRF Attack Example

Imagine a banking site has an endpoint:

POST /transfer/

Used to transfer money.

Now an attacker creates a malicious page:

1
2
3
4
5
6
7
8

<form action="https://bank.com/transfer/" method="POST">
    <input type="hidden" name="amount" value="5000">
    <input type="hidden" name="to" value="attacker">
</form>

<script>
    document.forms[0].submit();
</script>

If the victim visits that page while logged into bank.com:

1. Browser submits the form
2. Browser sends bank session cookie
3. Bank may process the transfer

The user never intended it.

That is CSRF.

Why the Attack Is Dangerous

The attacker does not need:

• The victim’s password
• Direct access to their account
• To steal cookies first

They only need:

• A logged-in victim
• A vulnerable site
• A way to make the victim load malicious content

Common Targets of CSRF

CSRF attacks target any action that changes state.

Examples:

• Password changes
• Email changes
• Money transfers
• Purchases
• Account deletion
• Posting content
• Admin actions
• Profile updates

GET vs POST and CSRF

Historically, some developers used GET requests for destructive actions:

https://site.com/delete/5/

That is dangerous because attackers can trigger GET requests through:

• Images
• Links
• Scripts
• Redirects

Example:

1

<img src="https://site.com/delete/5/">

If authenticated cookies are sent, damage may occur.

That is why: GET requests should not modify state.

How CSRF Works Technically

A successful CSRF attack usually depends on:

1. Browser Auto-Sending Credentials

Cookies/session auth automatically attached.

2. Predictable Endpoint

Attacker knows request URL and parameters.

3. No Request Authenticity Check

Server trusts cookies alone.

Why Same-Origin Policy Does Not Fully Stop CSRF

Browsers block many cross-origin reads, but often allow cross-origin requests to be sent.

Meaning attackers may not read responses, but they can still trigger actions.

Realistic Example: Profile Change

Suppose a vulnerable site accepts:

1
2

POST /change-email/
email=attacker@example.com

Attacker page:

1
2
3
4
5
6
7
8
9

<form action="https://victimsite.com/change-email/" method="POST">
    <input type="hidden"
           name="email"
           value="attacker@example.com">
</form>

<script>
    document.forms[0].submit();
</script>

1. Victim visits page while logged in.
2. Now account email may be changed.

How Frameworks Prevent CSRF

Modern frameworks like Django include CSRF protection by default.

A full article on Django's csrf_token can be found here: csrf_token in detail

They require a secret token in state-changing requests.

Example template:

1
2
3

<form method="post">
    {% csrf_token %}
</form>

The attacker’s external site cannot easily know the correct token.

So forged requests fail.

Common CSRF Defenses

1. CSRF Tokens

Most common defense.

Server issues secret token tied to session/browser state.

Legitimate forms include it:

1

<input type="hidden" name="csrfmiddlewaretoken" value="...">

Server validates token.

No token = reject request.

2. SameSite Cookies

Modern cookies can use:

1
2

SameSite=Lax
SameSite=Strict

This restricts when cookies are sent cross-site.

Very effective additional defense.

3. Origin / Referer Checks

Server validates request came from expected origin.

Useful especially on HTTPS sites.

4. Proper HTTP Methods

Use:

GET for reads POST/PUT/PATCH/DELETE for state changes

Then protect unsafe methods.

5. Reauthentication for Sensitive Actions

For high-risk changes:

• Re-enter password
• MFA challenge

Why SPAs / APIs Change the Picture

Many modern apps use:

• Bearer tokens
• Authorization headers
• Local storage tokens

Instead of cookie sessions.

If credentials are not automatically sent by browser, classic CSRF risk is reduced.

However, cookie-based APIs still need protection.

Real Impact of CSRF

Successful attacks can lead to:

• Unauthorized transactions
• Account takeover assistance
• Privilege changes
• Data modifications
• Reputation damage
• Legal/compliance issues

CSRF means: "The browser has credentials, but the request did not come from the real user's intent."

Best Practices for Developers

Use Framework Defaults

Modern frameworks already help.

Never Disable Protection Casually

Security exceptions should be rare.

Use SameSite Cookies

Strong browser-level defense.

Protect All State-Changing Requests

Not just login forms.

Separate Read vs Write Endpoints Properly

Good HTTP design matters.

Why CSRF Still Matters

Even though browser security has improved, many systems still rely on:

• Session cookies
• Admin panels
• Legacy forms
• Cookie-authenticated apps

That keeps CSRF relevant.

CSRF attacks exploit trust. The website trusts the browser because it carries valid credentials — but the browser may be acting under an attacker’s influence.