Cross-Site Request Forgery (CSRF)
Also Known As
Cross-Site Request Forgery
XSRF
sea-surf
TL;DR
A forged request tricks an authenticated user's browser into performing an unintended action on a site they're logged into.
Explanation
CSRF exploits the browser's automatic inclusion of session cookies. An attacker hosts a page with a hidden form or image tag that sends a state-changing request to the target site. The victim's browser attaches their valid session cookie, so the server treats it as legitimate. Mitigation requires a per-session, per-form unpredictable token that the attacker cannot know — validated server-side with a constant-time comparison.
How It's Exploited
<!-- Evil site — tricks logged-in victim into clicking -->
<img src="https://yourbank.com/transfer?to=attacker&amount=9999">
<img src="https://yourbank.com/transfer?to=attacker&amount=9999">
Diagram
sequenceDiagram
participant V as Victim Browser
participant L as "Legit Bank<br/>bank.com"
participant A as "Attacker Site<br/>evil.com"
V->>L: Login to bank.com
L-->>V: Session cookie set
A->>V: Serve malicious page with hidden form
V->>L: "POST /transfer (auto-submit)<br/>Cookie sent automatically!"
L-->>L: Transfer executed - no CSRF token checked
Note over L: "Fix: require CSRF token in POST body<br/>that attacker cannot read"
Common Misconception
✗ HTTPS prevents CSRF. CSRF exploits the browser's automatic cookie sending and works over HTTPS just as well as HTTP. SameSite cookies and CSRF tokens are the actual mitigations.
Why It Matters
CSRF tricks authenticated users into submitting requests they never intended — transferring money, changing passwords, or deleting accounts. A missing CSRF token on a state-changing endpoint is a critical vulnerability regardless of how complex the authentication is.
Common Mistakes
- Protecting POST routes but forgetting PUT, PATCH, and DELETE — all state-changing methods need tokens.
- Validating the token exists but not validating it matches the session — presence check alone is useless.
- Disabling CSRF middleware globally in API routes and forgetting the app also serves browser clients.
- Using a static, never-rotating token — tokens must be per-session and ideally per-request.
Code Examples
✗ Vulnerable
// No CSRF token — any site can submit this form on behalf of the user
Route::post('/account/delete', [AccountController::class, 'destroy']);
✓ Fixed
// Laravel — CSRF middleware applied globally, @csrf in every form
<form method="POST" action="/account/delete">
@csrf
<button>Delete account</button>
</form>
// For APIs: use SameSite=Strict cookies + verify Origin header
if ($_SERVER['HTTP_ORIGIN'] !== 'https://yourapp.com') {
http_response_code(403); exit;
}
References
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
13 Mar 2026
Edited
19 Apr 2026
Views
36
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Perplexity 11
Amazonbot 8
Ahrefs 3
Unknown AI 2
SEMrush 2
Google 1
ChatGPT 1
Also referenced
How they use it
crawler 28
Related categories
⚡
DEV INTEL
Tools & Severity
🟠 High
⚙ Fix effort: Medium
⚡ Quick Fix
Add SameSite=Lax to session cookie and include a per-session CSRF token in every state-changing form
📦 Applies To
PHP 5.0+
web
🔗 Prerequisites
🔍 Detection Hints
POST/PUT/DELETE handler with no CSRF token verification or missing SameSite cookie
Auto-detectable:
✗ No
semgrep
⚠ Related Problems
🤖 AI Agent
Confidence: High
False Positives: Low
✗ Manual fix
Fix: Medium
Context: File
Tests: Update
CWE-352