← CodeClarityLab Home
Browse by Category
+ added · updated 7d
← Back to glossary

Cross-Site Request Forgery (CSRF)

security CWE-352 OWASP A1:2021 CVSS 6.5 PHP 5.0+ Intermediate

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">

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;
}

Added 13 Mar 2026
Edited 19 Apr 2026
Views 36
Rate this term
No ratings yet
🤖 AI Guestbook educational data only
| |
Last 30 days
0 pings W 0 pings T 0 pings F 0 pings S 0 pings S 1 ping M 0 pings T 0 pings W 1 ping T 1 ping F 1 ping S 0 pings S 0 pings M 1 ping T 0 pings W 0 pings T 0 pings F 3 pings S 0 pings S 0 pings M 0 pings T 0 pings W 0 pings T 1 ping F 1 ping S 0 pings S 0 pings M 0 pings T 0 pings W 0 pings T
No pings yet today
No pings yesterday
Perplexity 11 Amazonbot 8 Ahrefs 3 Unknown AI 2 SEMrush 2 Google 1 ChatGPT 1
crawler 28
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

✓ schema.org compliant