0x55aa
← Back to Blog

CSRF: The Attack That Turns Your Users Into Unwitting Hackers 🕵️‍♂️💀

•7 min read
"cybersecurity""web-security""owasp""csrf""php""laravel"

CSRF: The Attack That Turns Your Users Into Unwitting Hackers 🕵️‍♂️💀

Picture this: Your app is running perfectly. Your users are happily logged in. Then someone sends them a cat meme link. They click it. And somehow — magically — their account email just changed to the hacker's address.

Your user didn't do anything wrong. Your server did everything correctly. And yet, you just got owned.

That, my friend, is Cross-Site Request Forgery (CSRF). And it's been ruining developers' days since the early web.

What the Heck is CSRF? 🤔

CSRF is when an attacker tricks a logged-in user's browser into making an unauthorized request to your server — without the user knowing.

Here's the brutal key insight: browsers automatically attach cookies to every request. That session cookie that keeps your user logged in? Yeah, it goes with EVERY request — including ones triggered by malicious third-party pages.

So if your bank's /transfer-funds endpoint accepts a POST request with just a cookie for authentication, an attacker can build a page that fires that exact request the moment an unsuspecting user visits it.

The user provides the authentication. The attacker provides the intent. Nobody wins (except the attacker).

A Classic CSRF Attack, Step by Step 🎬

Let's say your app has this endpoint:

POST /account/change-email
Cookie: session=abc123xyz

[email protected]

No CSRF protection. Just a POST with a cookie. Here's what an attacker does:

<!-- evil-cat-memes.com/index.html -->
<!DOCTYPE html>
<html>
<body onload="document.forms[0].submit()">
  <!-- Hidden form that auto-submits on page load -->
  <form action="https://yourbank.com/account/change-email" method="POST">
    <input type="hidden" name="new_email" value="[email protected]">
  </form>

  <p>Loading cat memes... 🐱</p>
</body>
</html>

The user opens the link. The page loads. The hidden form auto-submits to your server. The browser happily attaches the user's session cookie. Your server sees a valid authenticated request and changes the email.

The user sees a loading screen and some cat memes. They have no idea their account is already compromised.

That's it. That's the whole attack. No malware. No phishing for passwords. Just a sneaky HTML form and a browser that's "helpfully" doing its job.

Real-World CSRF Hall of Fame 😱

2008 — Netflix: Attackers could CSRF-add DVDs to someone's queue, change their shipping address, and even add secondary accounts. At scale, this was basically free DVD theft by remote control.

2008 — YouTube: CSRF allowed anyone to add videos to a user's favorites, subscribe to channels on their behalf, or flag innocent videos — all without the user's knowledge.

2012 — eBay: Multiple CSRF vulnerabilities let attackers modify listings, change account settings, and mess with bids on behalf of unknowing users.

The pattern? Huge companies. Simple oversight. Devastating results.

Why Your GET Requests Matter Too ⚠️

Most people think CSRF only hits POST. Nope.

If your app does anything state-changing via GET — you're extra vulnerable. GET requests can be triggered by:

  • <img src="https://yourapp.com/delete-account?confirm=yes">
  • <link rel="stylesheet" href="https://yourapp.com/logout">
  • Good old <a href="..."> that a user clicks without thinking

The fix here is simple but often forgotten: never use GET for state-changing operations. GET should be safe and idempotent. Always.

How to Actually Fix This 🛡️

Fix #1: CSRF Tokens (The Gold Standard)

The idea is elegant: include a secret, unpredictable token in every form that changes state. The attacker's site can't read your page (same-origin policy blocks it), so they can't forge the token.

// Generating a CSRF token (vanilla PHP)
session_start();
if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}
$token = $_SESSION['csrf_token'];

<!-- Include it in every state-changing form -->
<form action="/change-email" method="POST">
  <input type="hidden" name="csrf_token" value="<?= htmlspecialchars($token) ?>">
  <input type="email" name="new_email" placeholder="New email">
  <button type="submit">Update</button>
</form>

// Validate on the server side
session_start();
if (!hash_equals($_SESSION['csrf_token'], $_POST['csrf_token'] ?? '')) {
    http_response_code(403);
    die('CSRF token mismatch. Nice try. 👋');
}
// Safe to proceed

Why hash_equals instead of ===? Timing attack prevention. === can leak token length through response time. hash_equals is constant-time. Small thing, matters a lot.

Fix #2: Laravel Does It For You (Mostly) ✨

If you're on Laravel, the framework has had your back since day one:

// In routes/web.php — the VerifyCsrfToken middleware is already
// in your App\Http\Kernel.php $middlewareGroups['web'] array.
// It validates CSRF on all POST/PUT/PATCH/DELETE requests automatically.

Route::post('/change-email', [AccountController::class, 'changeEmail']);
// ↑ This is CSRF-protected. You're welcome.

<!-- In your Blade templates, just add @csrf -->
<form action="/change-email" method="POST">
    @csrf
    <input type="email" name="new_email" placeholder="New email">
    <button type="submit">Update</button>
</form>

That @csrf directive generates a hidden _token input. Laravel validates it on every non-GET request. Forget it and Laravel throws a 419 Page Expired error.

For AJAX requests, grab the token from the meta tag:

// In your main layout: <meta name="csrf-token" content="{{ csrf_token() }}">
// Then in your JS:
const token = document.querySelector('meta[name="csrf-token"]').content;

fetch('/change-email', {
    method: 'POST',
    headers: {
        'X-CSRF-TOKEN': token,
        'Content-Type': 'application/json',
    },
    body: JSON.stringify({ new_email: '[email protected]' }),
});

Laravel accepts CSRF tokens in both the _token POST field and the X-CSRF-TOKEN header. Axios (if you're using Laravel's default JS setup) does this automatically.

Fix #3: SameSite Cookies (Defense in Depth)

Modern browsers support a SameSite cookie attribute that prevents cookies from being sent on cross-site requests:

// PHP: Set the SameSite attribute
setcookie('session', $session_id, [
    'secure'   => true,
    'httponly' => true,
    'samesite' => 'Lax',  // Or 'Strict' for maximum protection
    'path'     => '/',
]);
  • Strict — Cookie is NEVER sent on cross-site requests. Most secure, but can break some legitimate flows (like following an email link to your logged-in page).
  • Lax — Cookie is sent on top-level navigation GETs but NOT on cross-site POST. This is the browser default in modern browsers. Stops most CSRF.
  • None — Sends on all requests. Requires Secure. Don't use this unless you have a very good reason.

The catch: SameSite alone isn't sufficient — old browsers don't support it, and some edge cases exist. Use it alongside CSRF tokens, not instead of them.

The CSRF Protection Checklist ✅

  • Never use GET for state-changing actions
  • Add CSRF tokens to ALL forms that create, update, or delete data
  • Validate CSRF tokens server-side on every state-changing request
  • Use hash_equals() for token comparison (not ===)
  • Set SameSite=Lax or Strict on session cookies
  • If using Laravel, verify @csrf is in every Blade form
  • For APIs consumed by your own JS: send the token in a header (X-CSRF-TOKEN)
  • For pure SPA + stateless JWT APIs: you may be safe (no cookies = no CSRF) — but double-check

The One Gotcha: Stateless APIs 🤯

If your API uses JWT tokens in Authorization headers (not cookies), CSRF is largely a non-issue. Attackers can't forge the Authorization header from a third-party site — only cookies are automatically attached.

But the moment you store JWTs in cookies for convenience? You're back in CSRF territory. The lesson: know where your auth lives and protect accordingly.

The Bottom Line 🎯

CSRF is one of those attacks that seems almost unfair — the attacker barely does anything, yet the damage is real. But it's also one of the easiest vulnerabilities to prevent if you build the habit in from the start.

The one-sentence fix: Include an unpredictable, user-specific token in every state-changing request, and validate it server-side.

In Laravel, that's just @csrf in your forms. In vanilla PHP, it's twenty lines of code. Either way, there's zero excuse not to have it.

Your users trusted you with their accounts. Don't let a hidden form on a cat meme site betray that trust.

Resources Worth Your Time 📚

Got CSRF war stories or questions? Find me on LinkedIn — I love comparing notes on web security!

More security deep-dives? Check out my GitHub for security-focused projects and code examples. 🛡️

Now go add @csrf to that one form you just remembered you forgot. You know the one. 😅

← Back to all posts