XSS vs. CSRF: Web Application Attacks Explained

There are countless ways to exploit systems, and it’s easy to fall behind on the nuances between different attack types. In penetration testing, companies often want specialists who can focus deeply on one area— web application security being one of the most in-demand.

Two of the most commonly misunderstood web application attacks are Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF). While both target web applications and can have a serious impact, they operate in fundamentally different ways.

This article breaks both down to their fundamentals and covers practical, real-world defenses.

What is Cross-Site Request Forgery (CSRF)?

CSRF is a relatively simple but highly impactful attack. At its core, CSRF exploits the fact that a web application trusts requests made by an authenticated user’s browser.

The Core Problem

A vulnerable application cannot verify whether a request was:

CSRF 2

Because, browsers automatically include session cookies with requests, attackers can abuse this trust.

How CSRF Works

An attacker creates a malicious webpage that silently triggers a request to a target application where the victim is already authenticated.

Example: GET-based CSRF

When a logged-in user visits this page:

-> Their browser automatically sends their session cookie

-> The request executes as if the user initiated it

POST-based CSRF

POST attacks are slightly more complex but follow the same concept.
Again, the victim:

  • Is authenticated
  • Visits the attacker’s page
  • Sends a forged request without realizing it

Why CSRF is Dangerous - and How to Defend

CSRF can allow attackers to:

CSRF Defenses (Best Practice)

  1. CSRF Tokens (Primary Defense)
    Unique, unpredictable tokens tied to user sessions. Verified server-side on every sensitive request.
  2. SameSite Cookies
    SameSite=Strict or Lax — prevents cookies from being sent in cross-site requests.
  3. Origin / Referer Validation
    Server checks where the request originated. Useful as a secondary control (not standalone).
  4. User Interaction Protections
    Re-authentication for sensitive actions. CAPTCHA or confirmation prompts.

What is Cross-Site Scripting (XSS)?

XSS is a completely different class of vulnerability. Instead of tricking the browser into making requests, XSS allows attackers to execute malicious JavaScript in another user’s browser.

The Core Problem

XSS occurs when an application inserts untrusted input into a webpage without proper sanitization or encoding.


The browser cannot distinguish between:

The Three Types of XSS

  1. Stored (Persistent) XSS
    Payload is saved on the server (e.g., comments, profiles). Every user who
    views the page is affected.
  2. Reflected XSS
    Payload is reflected immediately in a response (e.g., search results). Often
    delivered via malicious links.
  3. DOM-Based XSS
    Occurs entirely in client-side JavaScript. No server-side processing required.

Basic XSS Example

This confirms whether input is being executed as code.

Realistic Attack Example

This attempts to send cookies to the attacker.

What Attackers Actually Do With XSS

Instead of simple popups, real attackers may:
-> Steal session tokens (if accessible)
-> Perform actions as the victim (account takeover)
-> Inject backdoors into admin panels
-> Redirect users to phishing pages
-> Pivot into deeper application compromise

XSS Defenses (Best Practice)

  1. Output Encoding (Primary Defense)
    Encode user input based on context: HTML, JavaScript, URL, CSS.
  2. Input Validation & Sanitization
    Especially when HTML input is allowed. Use well-tested libraries (not custom regex).
  3. Safe DOM Handling
    Avoid dangerous sinks like innerHTML, document.write. Use textContent and safe templating frameworks.
  4. Content Security Policy (CSP)
    Restricts script execution. Limits impact if XSS occurs.
  5. Secure Cookies
    HttpOnly → prevents JavaScript access. Secure → HTTPS only.

Key Differences: CSRF vs XSS

They are often confused—but fundamentally different.

Building Secure Web Applications

Strong security requires:

Attackers are constantly evolving, and so should defenders. Understanding these fundamentals is a critical step toward building and testing secure web applications.

Josh is a Senior Security Consultant at Rotas Security.