While I was looking over some legacy code from a project I inherited the other day, I came across something that made me cringe. The previous developer had built an entire comment system where user input was being validated with a handful of regex patterns before rendering to the page. Little did I know at the time, but this approach was riddled with vulnerabilities that could have exposed the entire application to XSS attacks. I was once guilty of thinking that a few well-placed regex patterns were enough to keep malicious input at bay. I would strip out script tags, remove angle brackets, and call it a day. Looking back, I realize how naive that approach was. The world of web security is far more nuanced than simple pattern matching can handle. ## Why Input Sanitization Matters in Modern Web Applications Here's the reality: every single point where user input touches your application is a potential security vulnerability. Whether you're building a comment system, a rich text editor, or even a simple search form, you need to treat user input as hostile until proven otherwise. I cannot stress this enough! Modern web applications are incredibly complex, and attackers have become increasingly sophisticated. They're not just trying `{/* REMOVED: ` anymore. They're using obscure HTML attributes, SVG elements, and even CSS injection techniques to bypass naive sanitization attempts. The financial and reputational cost of a security breach is astronomical. When I finally decided to dive deep into input sanitization, I realized that the question isn't whether you should sanitize input, but how you should approach it effectively. ## Understanding the Difference: Validation vs Sanitization Before we jump into comparing specific approaches, let's clarify something fundamental that confused me for years: validation and sanitization are not the same thing. Validation is about rejection. You're checking if input meets specific criteria, and if it doesn't, you reject it entirely. Think of it like a bouncer at a club checking IDs. If your ID doesn't match the requirements, you're not getting in. Sanitization is about transformation. You're taking potentially dangerous input and making it safe by removing or encoding the harmful parts while preserving the legitimate content. It's more like a security checkpoint at an airport where they remove dangerous items but let you through. In other words, validation says "no" to bad input, while sanitization says "yes, but I'm going to clean this up first." ![Security comparison visualization](https://jsmanifest.s3.us-west-1.amazonaws.com/posts/dompurify-vs-manual-validation/content-1.jpg) ## DOMPurify: DOM-Based HTML Sanitization Explained When I came across DOMPurify for the first time, I was skeptical. Another library promising to solve all my security problems? I'd seen plenty of those fail spectacularly. But DOMPurify is different, and here's why. DOMPurify doesn't use regex or string manipulation to clean HTML. Instead, it leverages the browser's own HTML parser to create a DOM tree, then walks through that tree to remove dangerous elements and attributes. This is fascinating because it means DOMPurify understands HTML the same way browsers do, making it incredibly difficult to bypass with clever encoding tricks. The library was designed by security researchers who understand the nuances of XSS attacks. It handles edge cases that would take you years to discover on your own: mutation XSS, DOM clobbering, dangling markup injection, and countless other attack vectors I'd never even heard of when I started. Here's a basic example of DOMPurify in action: ```typescript import DOMPurify from 'dompurify'; // Dangerous user input const userInput = `

Hello World!

Click me

`; // Sanitize it const cleanHTML = DOMPurify.sanitize(userInput); // Result: '

Hello World!

Click me

' // All dangerous attributes and elements removed, safe content preserved ``` Wonderful! Notice how DOMPurify preserved the legitimate HTML structure while completely removing the dangerous parts. It didn't just strip out script tags—it also removed the onerror attribute and the {/* REMOVED: javascript: */} protocol from the link. ## Manual Validation Approaches: Regex, Whitelists, and Custom Logic Luckily we can learn from the mistakes I made with manual validation. Let me show you what I was doing wrong, and why it's so problematic. Here's the kind of code I used to write: ```typescript function sanitizeInput(input: string): string { // Attempt 1: Remove script tags let cleaned = input.replace(/)<[^<]*)*<\/script>/gi, ''); // Attempt 2: Remove event handlers cleaned = cleaned.replace(/on\w+\s*=\s*["'][^"']*["']/gi, ''); // Attempt 3: Remove javascript: protocol cleaned = cleaned.replace(/javascript:/gi, ''); // Attempt 4: Encode angle brackets cleaned = cleaned.replace(//g, '>'); return cleaned; } // Test with malicious input const maliciousInput = `

`; const result = sanitizeInput(maliciousInput); // This looks safe, but what about these bypasses? const bypass1 = `

`; // No quotes const bypass2 = `

`; // Capital E const bypass3 = `

{author}

); } ``` Notice how I'm using `useMemo` to ensure sanitization only happens when the content actually changes. I'm also configuring DOMPurify with a whitelist of allowed tags and attributes, which provides an additional layer of security by being explicit about what's permitted. ## When Manual Validation Makes More Sense Despite DOMPurify's power, there are scenarios where manual validation is the pragmatic choice. When I was building a form that collected structured data like addresses and phone numbers, I realized that rejecting invalid input was far more appropriate than trying to sanitize it. Consider a search query input. You don't want to allow HTML at all—you just want plain text. In this case, simple validation is perfect: ```typescript function sanitizeSearchQuery(query: string): string { // Remove all HTML tags and trim whitespace return query.replace(/<[^>]*>/g, '').trim().slice(0, 200); } ``` This is fast, predictable, and doesn't require any external dependencies. The ROI on learning and implementing DOMPurify for this use case would be negative. ## Building a Hybrid Sanitization Strategy The approach I've settled on after years of trial and error is using the right tool for the right job. Here's my framework: For rich content (comments, posts, descriptions): Use DOMPurify with strict configuration. Accept that users want formatting, but keep them in a safe sandbox. For structured data (forms, profiles, settings): Use validation to reject malformed input. Be strict about what you accept and reject everything else. For search and simple text: Strip all markup and enforce length limits. Don't overcomplicate it. For API inputs: Validate structure and types at the API boundary, then sanitize rich content fields before storage or display. This hybrid approach has saved me countless hours of debugging and has dramatically improved the security posture of every application I've worked on. The key is understanding that different types of input require different types of protection. And that concludes the end of this post! I hope you found this valuable and look out for more in the future!

Posts tagged “sanitization”

Input Sanitization: DOMPurify vs Manual Validation