XSS, CSRF, SQL Injection, and SSRF Explained with Real Stories

Web security sounds complex, but most real-world attacks come from a few common mistakes. In this article, we'll break down four major web vulnerabilities:

• XSS
• CSRF
• SQL Injection
• SSRF

We'll also look at how real systems get attacked and how developers prevent them.

1. XSS (Cross-Site Scripting)

🧠 What it is

XSS happens when an attacker injects malicious JavaScript into a website, and other users unknowingly run it in their browser.

📖 Real story

Imagine a comment section on a blog.

A user posts:

Great post! <script>alert('Hacked!')</script>

Great post! <script>alert('Hacked!')</script>

If the website does not clean input properly, every visitor will see that script run in their browser.

Attackers can:

• Steal cookies
• Hijack sessions
• Deface pages

🛡️ How to prevent it

XSS happens when user input is shown as code instead of plain text.

• Escape output before rendering Convert special characters like < and > into safe text so browsers don't execute them.
• Use Content Security Policy (CSP) Restrict which scripts the browser is allowed to run, blocking most injected scripts.
• Never render raw HTML from users Avoid innerHTML or equivalent unsafe rendering methods unless strictly sanitized.
• Use modern frameworks (React, Angular, etc.) They automatically escape output by default, reducing risk.

2. CSRF (Cross-Site Request Forgery)

🧠 What it is

CSRF tricks a logged-in user into performing unwanted actions on a site without their knowledge.

📖 Real story

Imagine you are logged into your bank.

You visit a malicious website in another tab.

That website secretly sends a request like:

Transfer $1000 to attacker account

Transfer $1000 to attacker account

Because you're already logged in, your browser automatically includes your session cookie. The bank thinks it's you.

🛡️ How to prevent it

CSRF works because the browser automatically sends cookies with requests.

• Use CSRF tokens Add a unique token to every request and validate it on the server.
• Set cookies with SameSite policy Use SameSite=Strict or Lax to prevent cross-site requests.
• Require re-authentication for sensitive actions Ask the user to confirm password or OTP for critical operations.
• Check Origin / Referer headers Ensure requests are coming from your trusted domain.

3. SQL Injection

🧠 What it is

SQL Injection happens when attackers manipulate database queries by injecting malicious SQL through input fields.

📖 Real story

A login form runs this query:

SELECT * FROM users
WHERE username = 'admin' AND password = '123'

SELECT * FROM users
WHERE username = 'admin' AND password = '123'

Attacker enters:

username: admin' --
password: anything

username: admin' --
password: anything

Query becomes:

SELECT * FROM users
WHERE username = 'admin' --' AND password = 'anything'

SELECT * FROM users
WHERE username = 'admin' --' AND password = 'anything'

The password check is ignored.

🛡️ How to prevent it

SQL Injection happens when user input becomes part of a SQL query.

• Use parameterized queries (prepared statements) Keep SQL logic and user input separate.
• Never concatenate user input into SQL Avoid building queries using string joins.
• Use ORM safely ORMs reduce risk, but still validate inputs properly.
• Apply least-privilege DB access Database users should only have required permissions, not full admin access.

4. SSRF (Server-Side Request Forgery)

🧠 What it is

SSRF happens when an attacker tricks your server into making requests to internal or restricted systems.

📖 Real story

A feature lets users fetch images from a URL:

https://yourapp.com/fetch-image?url=http://example.com/image.png

https://yourapp.com/fetch-image?url=http://example.com/image.png

Attacker changes it to:

http://localhost:8080/admin

http://localhost:8080/admin

Now your server requests its own internal admin panel and returns sensitive data.

🛡️ How to prevent it

SSRF happens when attackers force your server to call unintended URLs.

• Allowlist trusted domains only Only permit requests to known safe domains.
• Block internal IP ranges Prevent access to localhost, 127.0.0.1, 169.254.x.x, and private networks.
• Disable redirects in server requests Prevent attackers from bypassing restrictions.
• Validate and sanitize all URLs Ensure input is a valid, expected external URL format.

Wrapping Up

Most security vulnerabilities are not "advanced hacking tricks". They happen when user input is trusted too much.

A good rule of thumb:

Never trust input from the user — always validate, sanitize, and restrict it.

If you build APIs or web apps, understanding these four attacks already puts you ahead of many developers.

Thanks for reading ❤️ Follow me for more software architecture content.