Hey there! Since you've been digging into CSRF attacks lately, let's break down exactly what they are and the concrete, actionable ways to protect against them—no overly technical jargon, just straight-up useful info.

What is a CSRF Attack? #

CSRF (Cross-Site Request Forgery) is an attack where an attacker tricks a logged-in user into performing an unintended action on a website they're authenticated with. Think of it like this: you're logged into your online banking, then you click a sketchy link in an email. That link secretly sends a request to your bank's server (using your active login session cookie) to transfer money to the attacker's account—all without you realizing it.

The core issue here is that browsers automatically include cookies for a domain whenever a request is sent to that domain, even if the request comes from a completely different website. Attackers exploit this trust between your browser and the authenticated site.

How Do CSRF Attacks Typically Play Out? #

Here are a few common scenarios:

• A malicious email with a link that triggers a sensitive action (like changing your password or making a purchase) when clicked.
• A hidden image or script on a compromised forum/blog that sends a POST request to a target site (e.g., your social media account) to post spam.
• A fake website that looks legitimate, but submits forms to the real site using your saved session.

Practical Defense Methods #

These are the most effective, widely used ways to stop CSRF attacks:

1. CSRF Tokens #

This is the gold standard for most applications. Generate a unique, random token for each user session (or each request), include it in every form or sensitive API request, and verify it on the server side before processing the action.

Example in an HTML form:

<form action="/transfer-money" method="POST">
  <input type="hidden" name="csrf_token" value="aRandomLongString12345">
  <!-- Other form fields -->
  <button type="submit">Send Money</button>
</form>

On the backend, you'd check if the submitted csrf_token matches the one stored in the user's session. If not, reject the request.

2. SameSite Cookie Attributes #

Set the SameSite attribute on your session cookies to either Strict or Lax. This tells browsers only to send the cookie when the request originates from the same domain (Strict) or from a safe cross-domain context (like a link from another site, but not a form submission).

Example cookie header:

Set-Cookie: session_id=abc123; SameSite=Strict; Secure; HttpOnly

• Strict: Blocks the cookie in all cross-site requests (best for highly sensitive actions like banking).
• Lax: Allows the cookie in some cross-site requests (like following a link to your site from another page), which balances security and usability.

3. Verify Request Origin/Referer #

Check the Origin or Referer HTTP headers to ensure the request is coming from a trusted domain. For example, if your site is https://yourapp.com, reject any request where the Origin header isn't that exact value.

Note: Referer can sometimes be stripped by browsers or proxies, so Origin is more reliable when available.

4. Use HTTP POST for Sensitive Actions #

Never use GET requests for actions that modify data (like transferring money, changing settings, or deleting content). GET requests are easy to trigger via links or images, while POST requires explicit form submission or JavaScript—making CSRF attacks harder to pull off.

5. Double Submit Cookie (For Stateless Apps) #

If you're building a stateless application (like a JWT-based API), you can use the double submit cookie technique:

• Generate a random token, store it in a cookie.
• Include the same token in the request body or a custom header (e.g., X-CSRF-Token).
• On the backend, compare the cookie value and the request value—if they match, proceed.

This works because attackers can't read or modify cookies from another domain, so they can't include the correct token in their malicious request.

A Quick Example of a CSRF Attack #

Suppose an attacker creates a hidden image on a forum you visit:

<img src="https://your-bank.com/api/transfer?recipient=attacker&amount=1000" style="display:none;">

If you're logged into your bank when you load that forum page, your browser will send a GET request to the bank's API with your session cookie—transferring $1000 without you knowing. Using POST + CSRF tokens would stop this dead in its tracks.

内容的提问来源于stack exchange，提问作者NightOwl