# XSS Prevention in {/* REMOVED: JavaScript: */} 7 Essential Techniques While I was looking over some production code the other day, I came across a comment form that made my stomach drop. The developer had used `innerHTML` to display user comments directly on the page. Little did I know at the time, but this single line of code was a ticking time bomb that could compromise every user on the site. ## Understanding XSS Attacks: The Modern Web's Silent Threat I was once guilty of thinking XSS attacks were something that only happened to big companies with lax security. Then I watched a demonstration where someone injected a simple script tag into a comment field and stole session cookies from every visitor who viewed that page. That's when I realized: XSS isn't just a theoretical vulnerability—it's a practical threat that can destroy user trust overnight. Cross-Site Scripting happens when an attacker injects malicious scripts into web pages viewed by other users. The browser can't tell the difference between legitimate code and injected code, so it executes everything. I cannot stress this enough: if your application accepts any user input and displays it without proper handling, you're vulnerable. ## The Three Types of XSS Vulnerabilities Every Developer Must Know When I finally decided to take security seriously, I learned that XSS attacks come in three distinct flavors. Understanding these helped me identify vulnerabilities I'd been creating for years. **Stored XSS** is the most dangerous. The malicious script gets saved in your database and executed every time someone views that data. Think comment sections, user profiles, or forum posts. **Reflected XSS** happens when user input is immediately reflected back in the response. Search results that display "You searched for: [user input]" are classic examples. **DOM-based XSS** occurs entirely in the client-side JavaScript without server involvement. When I was building single-page applications, I was especially guilty of this one—manipulating the DOM with unsanitized data from URL parameters or localStorage. ![XSS Attack Vectors Diagram](https://jsmanifest.s3.us-west-1.amazonaws.com/posts/xss-prevention-javascript-techniques/content-1.jpg) ## Technique #1: Input Sanitization with DOMPurify The first line of defense is sanitizing user input before it ever touches your DOM. I used to try rolling my own sanitization functions, which is a terrible idea. You'll miss edge cases that attackers know about. DOMPurify is a battle-tested library that removes malicious code while preserving safe HTML. Here's how I use it in production: ```javascript import DOMPurify from 'dompurify'; // Bad: Never do this function displayComment(userComment) { document.getElementById('comments').innerHTML = userComment; // An attacker could submit:

} // Good: Sanitize before displaying function displayCommentSafely(userComment) { const clean = DOMPurify.sanitize(userComment, { ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p'], ALLOWED_ATTR: ['href'], ALLOWED_URI_REGEXP: /^(?:https?|mailto):/ }); document.getElementById('comments').innerHTML = clean; } // Example usage const maliciousInput = '

Great post!

'; displayCommentSafely(maliciousInput); // Output:

Great post!

// The script tag is completely removed ``` Notice how I explicitly whitelist allowed tags and attributes. This is crucial. In other words, I'm saying "only these specific things are allowed"—everything else gets stripped out. ## Technique #2: Content Security Policy (CSP) Headers Luckily we can add another layer of protection at the HTTP level. Content Security Policy headers tell the browser what sources of content are legitimate. When I first implemented CSP, I caught several third-party scripts I didn't even know were loading. ```javascript // Node.js/Express example app.use((req, res, next) => { res.setHeader( 'Content-Security-Policy', "default-src 'self'; " + "script-src 'self' https://trusted-cdn.com; " + "style-src 'self' 'unsafe-inline'; " + "img-src 'self' data: https:; " + "font-src 'self' https://fonts.gstatic.com; " + "connect-src 'self' https://api.yourapp.com; " + "frame-ancestors 'none'; " + "base-uri 'self'; " + "form-action 'self'" ); next(); }); // For static sites, add this meta tag to your HTML // ``` This header blocks inline scripts by default, which stops most XSS attacks cold. Yes, it requires refactoring inline event handlers like `onclick`, but that's actually a wonderful side effect—it forces you to write better, more maintainable code. ## Technique #3: Context-Aware Output Encoding Here's something I wish someone had told me years ago: there's no single "encode everything" function that works everywhere. The encoding you need depends entirely on where you're putting the data. ```typescript // Different contexts require different encoding class SecurityEncoder { // For HTML content static encodeHTML(str: string): string { return str .replace(/&/g, '&') .replace(//g, '>') .replace(/"/g, '"') .replace(/'/g, ''') .replace(/\//g, '/'); } // For JavaScript strings static encodeJS(str: string): string { return str .replace(/\\/g, '\\\\') .replace(/'/g, "\\'") .replace(/"/g, '\\"') .replace(/\n/g, '\\n') .replace(/\r/g, '\\r') .replace(/\//g, '\\/'); } // For URLs static encodeURL(str: string): string { return encodeURIComponent(str); } } // Example: Building a search results page function displaySearchResults(query: string, results: string[]) { // In HTML content const htmlSafe = SecurityEncoder.encodeHTML(query); document.getElementById('query-display').textContent = `Results for: ${htmlSafe}`; // In a JavaScript context (less common, but important) const jsSafe = SecurityEncoder.encodeJS(query); eval(`console.log("User searched for: ${jsSafe}");`); // Still avoid eval! // In a URL const urlSafe = SecurityEncoder.encodeURL(query); const shareLink = `https://yoursite.com/search?q=${urlSafe}`; } ``` ## Technique #4: Avoiding Dangerous DOM Methods This is where I made my biggest mistakes early on. The DOM API gives you several ways to insert content, and some are much safer than others. ```javascript const userInput = '

'; // DANGEROUS - Executes scripts element.innerHTML = userInput; // Result: XSS attack succeeds // SAFE - Treats everything as text element.textContent = userInput; // Result: Displays the literal string, no execution // SAFE - Creates actual text node const textNode = document.createTextNode(userInput); element.appendChild(textNode); // Result: Displays the literal string, no execution // SAFE - Uses DOM methods to build structure const paragraph = document.createElement('p'); paragraph.textContent = userInput; element.appendChild(paragraph); // Result: Text is safely contained in a paragraph element ``` When I finally decided to audit my codebase for `innerHTML` usage, I found dozens of potential vulnerabilities. Replacing them with `textContent` was tedious but straightforward. ![Safe DOM Manipulation Methods](https://jsmanifest.s3.us-west-1.amazonaws.com/posts/xss-prevention-javascript-techniques/content-2.jpg) ## Techniques #5-7: HTTP-Only Cookies, Trusted Types API, and Framework-Level Protection Let me share three more techniques that complete your XSS defense strategy. **Technique #5: HTTP-Only Cookies** prevent JavaScript from accessing sensitive cookies. When I set session cookies, I always include the HttpOnly flag: ```javascript // Server-side cookie setting res.cookie('sessionId', token, { httpOnly: true, // Cannot be accessed by JavaScript secure: true, // Only sent over HTTPS sameSite: 'strict' // Prevents CSRF attacks }); ``` **Technique #6: Trusted Types API** is a newer browser feature that forces you to use safe APIs. It's still gaining adoption, but I'm starting to use it in new projects: ```javascript // Create a policy for sanitized HTML const policy = window.trustedTypes.createPolicy('myPolicy', { createHTML: (string) => DOMPurify.sanitize(string) }); // Now innerHTML requires a TrustedHTML object element.innerHTML = policy.createHTML(userInput); ``` **Technique #7: Framework-Level Protection** is something modern frameworks handle automatically. React, Vue, and Angular escape values by default. But you can still shoot yourself in the foot: ```javascript // React example - SAFE by default function Comment({ text }) { return

{text}

; // Automatically escaped } // React - DANGEROUS override function UnsafeComment({ html }) { return

; // Only use this with sanitized content! } ``` ## Building an XSS-Proof Comment System: Real-World Implementation Let me show you how I put all these techniques together in a real comment system: ```typescript import DOMPurify from 'dompurify'; interface Comment { id: string; author: string; content: string; timestamp: Date; } class SecureCommentSystem { private container: HTMLElement; constructor(containerId: string) { this.container = document.getElementById(containerId)!; } displayComment(comment: Comment): void { // Create wrapper with safe DOM methods const wrapper = document.createElement('article'); wrapper.className = 'comment'; wrapper.setAttribute('data-comment-id', comment.id); // Author name - plain text, no HTML allowed const authorEl = document.createElement('strong'); authorEl.textContent = comment.author; // Timestamp - safe because it's a Date object const timeEl = document.createElement('time'); timeEl.textContent = comment.timestamp.toLocaleString(); // Content - sanitize if allowing rich text const contentEl = document.createElement('div'); const sanitized = DOMPurify.sanitize(comment.content, { ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'p', 'br'], ALLOWED_ATTR: [] }); contentEl.innerHTML = sanitized; // Assemble the comment wrapper.appendChild(authorEl); wrapper.appendChild(timeEl); wrapper.appendChild(contentEl); this.container.appendChild(wrapper); } // Safe comment submission async submitComment(author: string, content: string): Promise { // Client-side validation if (!author.trim() || !content.trim()) { throw new Error('Author and content are required'); } // Send to server - server MUST also sanitize! const response = await fetch('/api/comments', { method: 'POST', headers: { 'Content-Type': 'application/json', 'X-CSRF-Token': this.getCSRFToken() }, body: JSON.stringify({ author, content }) }); if (!response.ok) { throw new Error('Failed to submit comment'); } } private getCSRFToken(): string { // Get CSRF token from meta tag const meta = document.querySelector('meta[name="csrf-token"]'); return meta?.getAttribute('content') || ''; } } // Usage const commentSystem = new SecureCommentSystem('comments-container'); commentSystem.displayComment({ id: '123', author: 'John Doe', content: '

Great article!

', timestamp: new Date() }); // The script tag gets removed, but the paragraph stays ``` ## XSS Prevention Checklist and Security Audit Steps Here's the checklist I use when auditing code for XSS vulnerabilities: **Input Handling:** - [ ] All user input is sanitized with DOMPurify or equivalent - [ ] Input validation happens on both client and server - [ ] Maximum length limits are enforced **Output Encoding:** - [ ] `textContent` is used instead of `innerHTML` where possible - [ ] Context-appropriate encoding is applied - [ ] No `eval()` or `Function()` constructor with user data **HTTP Headers:** - [ ] Content-Security-Policy is configured - [ ] X-Content-Type-Options: nosniff is set - [ ] Cookies use HttpOnly, Secure, and SameSite flags **Framework Usage:** - [ ] Dangerous framework methods are avoided - [ ] Props and state are properly validated - [ ] Third-party components are audited **DOM Manipulation:** - [ ] No inline event handlers (`onclick`, etc.) - [ ] No `document.write()` with user data - [ ] URL parameters are validated before use I run through this checklist during code reviews and before every deployment. Fascinating how many issues you catch when you have a systematic approach. And that concludes the end of this post! I hope you found this valuable and look out for more in the future!

Posts tagged “xss”

XSS Prevention in 7 Essential Techniques