If you’re just getting into web security, you’ve probably heard of "Request Forgery." It sounds fancy, but in plain English, it just means tricking a system into doing something it didn't mean to do.

Two of the most common versions are CSRF and SSRF. They sound almost identical, and they both "forge" requests, but they work in very different ways. Let's break them down without the overly technical jargon.

What is CSRF? (The User Trick)

CSRF stands for Cross-Site Request Forgery. The easiest way to think about it is that the attacker is using your identity (your browser session) to perform actions on a website where you’re already logged in.

Imagine you're logged into your bank's website in one tab. In another tab, you visit a sketchy site that contains a hidden link. That link tells your browser to send a request to your bank: "Transfer $1,000 to this other account."

Because your browser already has the session cookies for your bank, it just sends the request. The bank sees a legitimate-looking request coming from your browser and processes it. You didn't click "Transfer," but the attacker "forged" that request using your authenticated session.

The main point: CSRF exploits the trust a website has in its users' browsers.

What is SSRF? (The Server Trick)

SSRF stands for Server-Side Request Forgery. This time, the victim isn't a person,it's the server itself.

In this attack, the hacker finds a way to tell the web server to make a request on their behalf. If a website has a feature that fetches data from a URL (like a profile picture from another site or a link preview), an attacker might provide an internal URL instead.

They might tell the server: "Hey, go fetch data from http://localhost/admin/config."

Normally, you couldn't access that admin page from the public internet. But since the request is coming from the server itself, it might have special permissions to see internal resources or other servers on the network that aren't exposed to the world.

The main point: SSRF exploits the trust a server has in itself or its internal network.

How are they different?

The biggest difference is who does the work. In CSRF, the attacker tricks the user's browser into sending a request. In SSRF, the attacker tricks the web server into sending a request.

With CSRF, the attacker wants to do things as you (like changing your password). With SSRF, the attacker usually wants to peek into private internal systems or steal sensitive metadata that the server has access to.

How do we stop them?

Securing a site isn't just about one fix, but here are the basics.

To stop CSRF, we use things like Tokens. Basically, every time you want to do something important (like a bank transfer), the site gives you a unique, secret code. If you send a request without that code, the site knows it wasn't you who actually clicked the button. We also use "SameSite" cookie settings to tell browsers not to send cookies when a request comes from another site.

To stop SSRF, we have to be very careful about what URLs the server is allowed to visit. We shouldn't just let it go anywhere. We use Whitelists (a list of "safe" sites the server can talk to) and make sure the server can't talk to its own "internal" addresses like localhost.

Why should you care?

Both of these are serious. A bad CSRF attack can let someone take over your accounts. A bad SSRF attack can lead to massive data breaches,like the famous Capital One breach in 2019, where an attacker used SSRF to steal records of over 100 million customers.

Understanding these basics is the first step in building (or testing) more secure applications. It’s all about knowing who is trusting who, and making sure that trust isn't being abused.