Cross-Site Request Forgery (CSRF) - The 5-Minute Ultimate Guide • Cyber Pulse Academy

POST /transfer HTTP/1.1

Cookie: session=abc123

GET /profile HTTP/1.1

Authorization: Bearer token

POST /change-password

X-CSRF-Token: valid

POST /transfer?to=attacker

POST /delete-account

POST /change-email

👤

VICTIM

Logged into bank.com
Session: Active

←→

🎭

ATTACKER

Malicious Page
Hidden Form

1 Victim is authenticated on bank.com

2 Victim visits attacker's malicious page (phishing link, ad, forum post)

3 Malicious page contains hidden form: <form action="bank.com/transfer">

4 Form auto-submits: transfer $5000 to attacker

5 Bank receives request with victim's legitimate session cookie

6 Transaction completed! Victim never knew it happened.

// SIMULATION: CSRF attack flow , exploiting browser session handling

WHY IT MATTERS

Cross-Site Request Forgery (CSRF) is a stealthy attack that forces authenticated users to perform actions they never intended. Unlike attacks that steal credentials, CSRF doesn't need to know your password, it hijacks your active session. The victim visits a malicious page while logged into a target site, and the attacker's code silently submits requests that the browser automatically authenticates with stored cookies. Banks, social media, email accounts, and administrative panels are all prime targets.

of all application layer attacks were CSRF (rising annually)

CWE-352

MITRE classification for CSRF vulnerabilities

Stateful

targets, CSRF only affects state-changing operations

According to OWASP's CSRF documentation, these attacks target functionality that causes state changes on the server, changing passwords, making purchases, transferring funds, or modifying account settings. The OWASP CSRF Prevention Cheat Sheet provides comprehensive guidance for developers.

The MITRE CWE-352 database classifies CSRF as a significant weakness, noting that standard authentication mechanisms don't prevent it because the browser automatically includes credentials with requests, exactly what attackers exploit.

KEY TERMS & CONCEPTS

Simple Definition

Cross-Site Request Forgery (CSRF) is an attack that tricks a web browser into executing an unwanted action on a trusted site where the user is currently authenticated. The attack works because browsers automatically include cookies and authentication data with every request to a given site, even requests originating from other sites. If a user is logged into their bank and visits a malicious page, that page can silently submit a money transfer request that the bank's server will honor because it appears to come from the authenticated user.

                <!-- Attacker's malicious HTML page -->

                <form action="https://bank.com/transfer" method="POST">

                  <input type="hidden" name="to" value="attacker-account"/>

                  <input type="hidden" name="amount" value="5000"/>

                </form>

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

                // Browser automatically includes bank.com cookies!

Everyday Analogy

Imagine you've checked into a hotel and received a key card for your room. While you're at the hotel bar, someone approaches the front desk and says "Please charge a $500 dinner to room 302, I'm the guest there." The desk clerk sees a valid key card in the person's hand (which they stole a glimpse of) and processes the charge. You never authorized it, but the hotel accepted the request because it came with valid credentials. In CSRF, the attacker's website sends requests to a target site using your browser's stored "key cards" (cookies), and the server accepts them because they appear legitimate.

REAL-WORLD SCENARIO

🏦

The Social Media Takeover

How Jennifer discovered her company's social media had been hijacked

Jennifer, a marketing manager at a mid-sized company, managed the company's main social media accounts. One morning, she received a message from a colleague asking why she had posted controversial political content on the company's timeline. Confused, Jennifer checked the account, and found dozens of inflammatory posts she had never made. Her immediate reaction was that her password had been stolen, but a security investigation revealed something more subtle.

The attack had started three days earlier. Jennifer had clicked on a link in an email that appeared to be from a marketing analytics platform. The link took her to a legitimate-looking page about social media metrics, but hidden on that page was a form that auto-submitted a request to the social media platform. Because Jennifer was logged into her company's account in another browser tab, the platform accepted the request as if she had made it herself, adding the attacker as an administrator with full posting privileges.

The attacker could then post content, send messages, and even remove Jennifer's own admin access. The platform had no CSRF protection on its "add administrator" function, making the attack trivial to execute. Jennifer learned that password security wasn't enough, she needed to understand session-based attacks and always verify that sensitive actions require explicit confirmation beyond just being logged in.

Before Understanding CSRF

• No CSRF tokens on sensitive forms
• GET requests for state changes
• No re-authentication for admin actions
• Trusting requests from authenticated sessions

After Implementing Protection

• CSRF tokens on all state-changing forms
• POST/PUT for all modifications
• Password confirmation for admin changes
• SameSite cookie attribute enabled

STEP-BY-STEP GUIDE

Implement CSRF Tokens

Generate a unique, unpredictable token for each session and include it in forms
Validate the token on the server before processing any state-changing request
Use framework-provided CSRF protection (Django, Rails, Laravel, etc. have built-in support)

Use SameSite Cookie Attribute

Set SameSite=Strict or SameSite=Lax on session cookies to prevent cross-site submission
Strict blocks all cross-site requests; Lax allows safe navigation but blocks forms and AJAX
This is now the default in modern browsers but should be explicitly configured

Enforce POST for State Changes

Never use GET requests for actions that modify data (transfers, deletes, updates)
GET requests can be triggered via image tags, links, and browser prefetching
Use POST, PUT, or DELETE for all state-modifying operations

Require Re-authentication for Sensitive Actions

Ask for password confirmation before critical operations (changing email, large transfers)
This prevents CSRF even if tokens are compromised or not implemented
Consider multi-factor authentication for high-value transactions

Validate Request Origin

Check the Origin and Referer headers to verify requests come from your domain
Reject requests with missing or mismatched origin headers on sensitive endpoints
Note: Headers can be spoofed in some circumstances, so use alongside tokens

Implement Custom Request Headers

Require custom headers (like X-Requested-With) on AJAX requests
Cross-origin requests cannot include custom headers without CORS preflight approval
This adds an additional layer of protection for API endpoints

Test and Monitor

Include CSRF testing in security assessments and penetration tests
Use security scanners that check for missing CSRF protection
Monitor logs for unusual patterns of requests from different origins

Cross-Site Scripting (XSS) Session Hijacking Clickjacking Authentication Bypass

COMMON MISTAKES & BEST PRACTICES

✗ Common Mistakes

Using GET requests for state-changing operations (deletes, transfers, updates)
Checking only Referrer header without CSRF tokens, headers can be missing or spoofed
Using predictable tokens or tokens that don't change per session
Forgetting to validate CSRF tokens on AJAX/API requests
Assuming HTTPS prevents CSRF, it doesn't; HTTPS only protects data in transit

✓ Best Practices

Implement CSRF tokens on all forms that perform state-changing actions
Use SameSite=Strict cookie attribute as defense-in-depth
Require POST/PUT/DELETE methods for all modifications
Add re-authentication for critical operations like password changes or large transfers
Use framework built-in CSRF protection rather than implementing your own

RED TEAM vs BLUE TEAM VIEW

🔴 Red Team Perspective

I hunt for endpoints that change state without CSRF protection, password changes, email updates, fund transfers, API key generation. I craft malicious pages that submit hidden forms to these endpoints while the victim is authenticated. Social engineering helps me get targets to visit my malicious page, phishing emails, forum posts, or even legitimate sites compromised with injected scripts. If I find a site without CSRF protection, I can potentially force victims to transfer funds, change their email (account takeover), or perform any action they're authorized to do. The key is finding high-value actions that lack proper validation.

🔵 Blue Team Perspective

Defense against CSRF is straightforward when done systematically. We ensure every state-changing form includes a CSRF token that's validated server-side. We configure SameSite cookies to prevent cross-site submission. We require re-authentication for sensitive operations, especially those that could lead to account takeover. Our security headers include X-Frame-Options and Content-Security-Policy to prevent embedding. We test regularly for CSRF vulnerabilities, especially in new features and API endpoints. Defense-in-depth is key: tokens, cookie attributes, origin validation, and re-authentication together create robust protection.

THREAT HUNTER'S EYE

Safe, Legal, Non-Technical Exploration

Understanding CSRF doesn't require technical skills. Consider this everyday scenario: You're logged into your email account in one browser tab. In another tab, you visit a website that has a "Share via Email" button. When you click it, your email compose window opens with the link pre-filled. This is legitimate cross-site functionality. CSRF works similarly but maliciously, a page you visit can trigger your browser to send requests to other sites where you're logged in, and those sites may honor the requests without knowing you didn't intentionally make them.

To understand CSRF safely, practice on intentionally vulnerable applications like OWASP WebGoat or the CSRF labs at PortSwigger Web Security Academy. These environments let you experience both the attacker's perspective (crafting malicious pages) and the defender's perspective (implementing tokens and cookie protections). Never test CSRF techniques on real websites without explicit permission, unauthorized testing is illegal and can result in criminal charges.

Questions About CSRF Protection?

Have you encountered CSRF vulnerabilities in your applications? Questions about implementing CSRF tokens or SameSite cookies? Share your thoughts and questions below. Understanding CSRF is essential for building secure web applications.

We keep threat intelligence free. No paywalls, no ads. Your donation directly funds server infrastructure, research, and tools.