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:
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)
CSRF Tokens (Primary Defense) Unique, unpredictable tokens tied to user sessions. Verified server-side on every sensitive request.
SameSite Cookies SameSite=Strict or Lax — prevents cookies from being sent in cross-site requests.
Origin / Referer Validation Server checks where the request originated. Useful as a secondary control (not standalone).
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
Stored (Persistent) XSS Payload is saved on the server (e.g., comments, profiles). Every user who views the page is affected.
Reflected XSS Payload is reflected immediately in a response (e.g., search results). Often delivered via malicious links.
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)
Output Encoding (Primary Defense) Encode user input based on context: HTML, JavaScript, URL, CSS.
Input Validation & Sanitization Especially when HTML input is allowed. Use well-tested libraries (not custom regex).
Safe DOM Handling Avoid dangerous sinks like innerHTML, document.write. Use textContent and safe templating frameworks.
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.