FrontendPrep
Menu
Topics
Questions
Guides
Challenges
Soon
Back to Web Security Questions
securityHard

Mitigating XSS and CSRF in Web Applications

Master client-side web security. Learn how Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) work, how they differ, and complete mitigation strategies.

Mitigating XSS and CSRF in Web Applications

A core requirement for senior engineering positions is designing secure client-side applications. A standard security question is:

Explain the difference between XSS and CSRF. How do they work, and what security measures must be implemented to prevent them?

To answer this, you must analyze how attackers exploit trust in web clients, how cookies are managed, and how user inputs are handled.


1. Cross-Site Scripting (XSS)

What Is It?

XSS occurs when an attacker successfully injects malicious scripts (usually JavaScript) into a trusted website, executing code within the victim's browser session.

Types of XSS:

  1. Stored (Persistent) XSS: The malicious script is permanently stored on the target server (e.g., in a database, comment field, or profile description) and served to other users.
  2. Reflected (Non-Persistent) XSS: The script is embedded within a request parameter (e.g., in a URL search query) and reflected back immediately by the server response.
  3. DOM-based XSS: The vulnerability lies entirely in client-side code, where user input is unsafely written directly to the DOM (e.g., using element.innerHTML or document.write).

Mitigations:

  • Sanitize and Escape Input: Encode all user input before rendering it in the browser (e.g., convert < to &lt;). Use templating engines (like React) that escape values by default.
  • Use Secure Cookie Headers: Protect session cookies from being accessed by JavaScript (document.cookie) by setting the HttpOnly flag.
  • Implement a Content Security Policy (CSP): Limit where scripts can be loaded from.

2. Cross-Site Request Forgery (CSRF)

What Is It?

CSRF is an attack that forces a user to execute unwanted actions on a web application in which they are currently authenticated. The attacker exploits the browser's default behavior of automatically attaching cookies (including session cookies) to outgoing cross-site requests.

Example Scenario:

A user is logged into their bank account (bank.com). They visit a malicious site that contains a hidden image or form:

<img src="https://bank.com/transfer?amount=1000&to=attacker" />

The browser sends this request to bank.com, automatically sending the user's session cookies. The bank processes the transfer thinking it was authorized by the user.

Mitigations:

  • SameSite Cookie Attribute: Restrict cookies from being sent on cross-site requests:
    • SameSite=Strict: Cookies are never sent on cross-site requests.
    • SameSite=Lax: Cookies are sent on safe top-level navigations (like links), which is the default in modern browsers.
  • Anti-CSRF Tokens (Double Submit Cookie): Generate a unique, cryptographically secure token on the server for each user session. Any state-changing request (POST/PUT/DELETE) must include this token in a header. The server verifies this token before processing.

3. Comparison Summary

AttackExploits...GoalPrimary Defense
XSSTrust the user has in site scriptsRun malicious code in browserContextual Output Encoding, CSP
CSRFTrust the site has in user browserExecute unauthorized commandsSameSite Cookies, Anti-CSRF Tokens

Key Takeaways

  • Core Difference: XSS injects malicious client-side code, whereas CSRF forces the browser to execute unauthorized commands.
  • XSS Protection: Use HttpOnly cookies to prevent session tokens from being stolen via XSS.
  • CSRF Defense: Use SameSite=Lax or SameSite=Strict cookies alongside CSRF tokens to neutralize CSRF attacks.

Share this Resource

Help other developers level up by sharing this study guide.

More Technical Questions

Expand your mastery. Deep dive into other frontend interview challenges in this category.