What is a CSRF Attack?

Welcome to this reading on Cross-Site Request Forgery (CSRF)! Think of it like someone forging your signature on important documents. In a CSRF attack, an attacker exploits a user's logged-in status to make malicious requests on that user's behalf—much like if they had stolen your pen and signature stamp. By doing so, the attacker inherits the identity of the user to perform actions without that user’s knowledge or consent.

In this reading, you’ll learn:

• What a CSRF attack is
• Real-world examples of a CSRF attack
• How to secure your application against a CSRF attack

Understanding CSRF

A CSRF attack is a trick: it convinces a logged-in user to send a malicious request to a vulnerable application. Because the user is already authenticated, the server thinks the request is legitimate. The consequences can be severe, including:

• Exposing private or personal data to attackers
• Manipulating the user’s account (e.g., transferring money, changing passwords)
• Logging a user into an attacker’s account to harvest data
• Stealing sensitive credentials or session tokens

Think of it like a house with a doormat that says “Welcome, John.” If you can fool John into stepping on the doormat and opening the door, you gain access to his entire house. CSRF exploits the user’s ongoing session to slip in unnoticed.

Example 1: Form Submission to a Vulnerable Server

A classic example of CSRF involves a malicious website embedding a form that points to another site. If the other site doesn’t have CSRF protections in place, your browser automatically attaches your session cookies, making it seem like you performed the action intentionally. A sample form might look like this:

<form action="http://bank.com/transfer.do" method="POST">
    <input type="hidden" name="acct" value="MARIA" />
    <input type="hidden" name="amount" value="100000" />
    <input type="submit" value="View my pictures" />
</form>

When a user with a valid session at bank.com clicks “View my pictures,” it actually sends a high-value bank transfer request. If the server trusts the existing session without checking for CSRF tokens, that transfer could succeed.

Proper CSRF protection would prevent this from happening, since the server would look for a valid CSRF token in the request before allowing such a critical action.

Example 2: Fake Website Imitates the Original

Another method is setting up an entirely fake website that mirrors your real one. Users might think they’re logging into your official site, but they’re actually handing their data to an attacker. Even if you protect your site with standard CSRF tokens, users can still be tricked into entering sensitive info (like passwords or Social Security numbers) on a counterfeit site.

A real-world analogy is a scammer building a perfect replica of your coffee shop, right down to the menu and branding, but the “shop” is collecting your credit card and personal information under false pretenses.

While standard CSRF defenses might not foil a perfect imitation site, common countermeasures include branding consistency, user-specific markers, and encouraging users to double-check URLs. Some sites place personal watermarks or images to reassure users they’re on the correct domain.

Securing Your Application Against CSRF Attacks

At App Academy, you’ll focus on preventing the first type of CSRF attack—where a malicious form or link attempts to leverage a user’s authenticated session to make unauthorized requests. The typical method involves issuing CSRF tokens. Here’s the basic flow:

• Create two CSRF tokens – one encrypted, one decrypted.
• Place the decrypted token in a readable cookie – your frontend JavaScript can read this token and attach it to requests.
• Place the encrypted token in an HTTP-only, Same-Site cookie – this protects it from being accessed by third-party scripts or other domains.
• Frontend attaches the decrypted token to each request – typically added in the request headers.
• Backend validates both tokens – it decrypts the cookie-based token and checks if it matches the token in the request headers.

Because only your backend knows the private key used to encrypt and decrypt the tokens, attackers can’t easily forge them. Requests lacking a valid token pair will be rejected, nullifying the attempt to hijack a user’s session.

Step by Step Visualization

Imagine you’re passing two matching puzzle pieces between the server and your application’s frontend:

• You (the server) generate a “public” puzzle piece (decrypted CSRF token) and a “secret” puzzle piece (encrypted token).
• You hide the “secret” piece in a protected, Same-Site cookie, and give the “public” piece to the browser in a readable cookie.
• The browser places the “public” piece in the request header for any action that modifies data or is critical to user security.
• The server checks whether the “public” piece (header) can be matched to the “secret” piece (cookie) using its internal cryptographic key.
• If they match, the request is legitimate. If not, the request is rejected.

With this system in place, a random malicious site can’t produce a valid puzzle piece pair, foiling attempts to masquerade as your user.

What You Have Learned

In this reading, you explored:

• What a CSRF attack is: A malicious exploit that forces unauthorized actions on behalf of an authenticated user.
• Examples of how CSRF can appear: Fake forms and phishing sites that abuse active sessions.
• A method to prevent it: Matching encrypted and decrypted CSRF tokens to verify genuine requests.

CSRF attacks can be extremely damaging, but with a robust token-based strategy, you ensure that only legitimate requests pass through. As you build more complex apps, keep in mind that user authentication and session security go hand in hand with preventing CSRF. By understanding and implementing these defenses, you’ll protect both your users and your platform from a major threat in the web security landscape.