Skip to main content
Web Application Vulnerabilities
CHAPTER 06

Cross-Site Request Forgery (CSRF)

Updated: May 15, 2026
20 min read

# CHAPTER 6

Cross-Site Request Forgery (CSRF)

1. Introduction

In the previous chapters, we protected our application from attackers stealing data. But what if the attacker doesn't want to steal your data; what if they want to *use* your data? Cross-Site Request Forgery (CSRF) is a devious attack where a hacker forces an innocent user's browser to execute unwanted actions on a website where the user is currently authenticated. In this chapter, we will learn how the browser's automatic cookie handling creates this vulnerability and how to implement Anti-CSRF Tokens to stop it.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Define Cross-Site Request Forgery (CSRF).
  • Understand how browsers automatically attach session cookies to requests.
  • Analyze the mechanics of a CSRF attack on state-changing actions.
  • Implement Anti-CSRF Tokens (Synchronizer Tokens) in web forms.
  • Understand the defense-in-depth provided by the SameSite cookie attribute.

3. Beginner-Friendly Explanation

Imagine you are at an exclusive club, and the bartender knows you by your face (Your Session Cookie).
  • You can say to the bartender, "Transfer $100 from my tab to Bob's tab," and the bartender does it because they recognize your face.
  • The Exploit (CSRF): A thief walks up behind you, points a gun at your back, and whispers, "Tell the bartender to transfer $100 to the thief's tab." You say the words out loud.
  • The bartender looks at your face, recognizes you, and processes the transfer. The bartender doesn't know you were forced to make the request.

CSRF happens when a hacker forces your browser to "say the words" to the bank, and because the bank recognizes your browser's cookie, it processes the malicious request.

4. The Anatomy of a CSRF Attack

For CSRF to work, three things must be true:
  1. 1. The victim must be logged into the target site (e.g., bank.com).
  1. 2. The attacker must trick the victim into visiting a malicious site (e.g., hacker.com).
  1. 3. The targeted action must be predictable (e.g., bank.com/transfer?amount=100&to=hacker).

The Attack: The victim visits hacker.com. The hacker's HTML code contains a hidden image tag: <img src="https://bank.com/transfer?amount=100&to=hacker" width="0" height="0">

When the browser tries to load the image, it makes a GET request to bank.com. Because the victim is logged into bank.com, the browser *automatically attaches the victim's session cookie*. The bank receives the request, sees the valid cookie, assumes the user genuinely wanted to transfer the money, and processes it.

5. The Primary Defense: Anti-CSRF Tokens

To stop CSRF, the bank must ensure the request actually originated from the bank's own HTML form, not from a hidden image on hacker.com. We use an Anti-CSRF Token (Synchronizer Token Pattern).
  1. 1. When the server loads the legitimate transfer form, it generates a long, cryptographically random, one-time token (e.g., 8f7b2c...).
  1. 2. It saves this token in the user's session, and embeds it as a hidden field in the HTML form.
  1. 3. When the user submits the form, the token is sent back. The server compares the submitted token to the session token.
Because the hacker on hacker.com cannot see the bank's HTML page, they cannot guess the random token. Their forced request will be missing the token, and the bank will reject it.

6. Mini Project: Add CSRF Protection to Forms

Let's conceptualize this defense in PHP.

Step 1: Generate the Token on the Form Page

php
123456789101112 
session_start();
// Generate a strong random token if one doesn't exist
if (empty($_SESSION[&#039;csrf_token'])) {
    $_SESSION[&#039;csrf_token'] = bin2hex(random_bytes(32));
}
?>
<!-- The HTML Form -->
<form action="transfer.php" method="POST">
    <input type="hidden" name="csrf_token" value="<?php echo $_SESSION[&#039;csrf_token']; ?>">
    <input type="text" name="amount" placeholder="Amount">
    <button type="submit">Transfer</button>
</form>

Step 2: Validate the Token on the Processing Page

php
123456 
session_start();
// Verify the token submitted matches the token in the session
if (!isset($_POST[&#039;csrf_token']) || $_POST['csrf_token'] !== $_SESSION['csrf_token']) {
    die("CSRF Token Validation Failed. Request Denied.");
}
// Proceed with the transfer...

7. Modern Browser Defense: SameSite Cookies

Modern browsers have introduced a powerful defense-in-depth attribute for cookies called SameSite. If a developer sets the cookie attribute to SameSite=Lax or SameSite=Strict, the browser will refuse to attach the session cookie if the request originates from a different domain (like hacker.com). This effectively kills traditional CSRF attacks at the browser level, though CSRF tokens are still mandatory for high-security applications.

8. Real-World Scenarios

In 2008, Netflix had a CSRF vulnerability. An attacker could craft a malicious webpage containing hidden requests targeting Netflix's API. If a logged-in Netflix user visited the attacker's page, the hidden request would silently add the attacker's home address to the victim's Netflix account and order DVDs to be shipped to the attacker, all billed to the victim's account. Netflix resolved this by implementing strict anti-CSRF tokens on all state-changing API endpoints.

9. Best Practices

  • Never Use GET for State-Changing Actions: An HTTP GET request should only be used to retrieve data. It should never be used to delete a user, transfer money, or change a password. GET requests are trivial to exploit via CSRF (e.g., an <img> tag). Always use POST, PUT, or DELETE for actions that change state, and protect them with CSRF tokens.

10. Legal and Ethical Notes

CSRF attacks often leave the victim feeling responsible for the action, as the logs show the request originated from the victim's IP address with their valid session. In a forensic investigation, demonstrating the absence of CSRF tokens on critical forms is vital to proving the user was a victim of forgery, not an active participant in the malicious action.

11. Exercises

  1. 1. Explain why Cross-Site Request Forgery (CSRF) is completely dependent on the browser's automatic handling of session cookies.
  1. 2. How does an Anti-CSRF token prove to the server that the request originated from the legitimate web application rather than an attacker's website?

12. FAQs

Q: Do APIs using JSON Web Tokens (JWTs) need CSRF protection? A: Usually, no. If your API requires the client (like a mobile app or a React frontend) to manually attach the JWT in the Authorization: Bearer header, you are immune to CSRF. CSRF only works when the browser *automatically* attaches credentials (like Cookies).

13. Interview Questions

  • Q: Describe the mechanics of a Cross-Site Request Forgery (CSRF) attack and the standard Synchronizer Token Pattern used to mitigate it.
  • Q: A developer argues that they do not need CSRF tokens because they have configured their session cookies with the SameSite=Strict attribute. From a defense-in-depth perspective, how do you evaluate this architecture?

14. Summary

In Chapter 6, we uncovered the dangers of ambient authority. We learned that Cross-Site Request Forgery (CSRF) exploits the browser's helpful nature of automatically attaching session cookies to requests, allowing attackers to forge actions on behalf of logged-in users. We implemented the definitive countermeasure: cryptographically random Anti-CSRF tokens, ensuring that all state-changing requests originate exclusively from intended, legitimate application interfaces.

15. Next Chapter Recommendation

We've secured our forms from forgery, but what if the user intentionally submits a malicious file through those forms? Proceed to Chapter 7: File Upload Security.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter SQL Injection Awareness
Next Chapter File Upload Security

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 4

❓ Related Quizzes 5