DEV Community

Cover image for Mastering Data Sanitization in Legacy React Applications: A Lead QA Engineer's Approach
Bishoy Semsem
Bishoy Semsem

Posted on • Originally published at bishoy-bishai.github.io

Mastering Data Sanitization in Legacy React Applications: A Lead QA Engineer's Approach

#react #webdev

Mastering Data Sanitization in Legacy React Applications: A Lead QA Engineer's Approach

Alright, let's grab that coffee. Because if you've spent any time working on a legacy React application, you know the feeling. It's like inheriting a beautiful old house; it has character, history, and probably a few hidden structural issues that only reveal themselves when a new storm rolls in. For us as developers and QA engineers, that "storm" often comes in the form of unsanitized user input.

I've been on engineering teams where a seemingly innocent text field, perhaps for a user's "about me" section, suddenly becomes a vector for XSS attacks, or worse, just plain breaks the UI with unclosed HTML tags. The bug report lands, and you're thinking, "Wait, how did that get through?" In my experience, these moments often highlight a gap in our understanding of data sanitization, especially when dealing with the accumulated technical debt of older React codebases.

The Elephant in the Room: Why Sanitization Matters (Beyond XSS)

When we talk about data sanitization, most developers immediately jump to Cross-Site Scripting (XSS). And they're right to – preventing alert('pwned') is paramount. But here's the thing: sanitization isn't just about security. It's about data integrity, predictable UI rendering, and maintaining a stable user experience.

Imagine a user pastes content from a poorly formatted website directly into a rich text editor. Without proper sanitization, you might end up with unwanted <iframe> tags, inline styles breaking your design system, or even base64 encoded images that bloat your database. In legacy apps, where different parts might have been built with varying levels of security awareness, these inconsistencies multiply. Server-side validation is crucial, absolutely. But relying solely on it in a complex frontend can be a recipe for disaster. The client-side is your last line of defense, and it's where React shines in providing mechanisms for control.

Diving Deep: Client-Side Sanitization in React

So, how do we tackle this in React, particularly when the codebase isn't fresh off the compiler?

1. Understanding the Core Problem: Displaying User Input

The most common mistake I've observed is the assumption that <span>{userInput}</span> is always safe. While React does a fantastic job of escaping string values by default (meaning < becomes &lt;), this prevents HTML injection, but not necessarily logic injection if you're dealing with a rich text field or markdown.

The real danger often lies when you intentionally render HTML from user input, typically using dangerouslySetInnerHTML. The name itself is a warning, and for good reason. It bypasses React's protection.

// The classic no-no without sanitization
function UnsafeComponent({ rawHtml }) {
  return <div dangerouslySetInnerHTML={{ __html: rawHtml }} />;
}
Enter fullscreen mode Exit fullscreen mode

This is where a robust sanitization library becomes your best friend. In my projects, I've found DOMPurify to be an absolute lifesaver. It's fast, widely used, and incredibly configurable.

2. Building a Safe Abstraction: The SanitizedText Component

Instead of scattering DOMPurify.sanitize() calls everywhere, which can be hard to maintain and prone to inconsistencies, I always advocate for creating a centralized, reusable component or hook.

// components/SanitizedText.tsx
import React from 'react';
import DOMPurify from 'dompurify';

interface SanitizedTextProps {
  htmlContent: string | null | undefined;
  className?: string;
  tagName?: keyof HTMLElementTagNameMap; // To allow rendering as p, span, div, etc.
  config?: DOMPurify.Config; // Allow custom DOMPurify configurations
}

const defaultDOMPurifyConfig: DOMPurify.Config = {
  USE_PROFILES: { html: true }, // Default to a robust HTML profile
  FORBID_ATTR: ['style'], // Often want to strip inline styles
  ADD_TAGS: ['iframe', 'img'], // Example: allow iframes and images, but DOMPurify will still check their attributes
  ADD_ATTR: ['allowfullscreen', 'frameborder', 'src', 'alt', 'width', 'height'],
  // Be very specific about what you allow based on context!
};

const SanitizedText: React.FC<SanitizedTextProps> = ({
  htmlContent,
  className,
  tagName: Tag = 'div', // Default to div if no tagName is provided
  config = defaultDOMPurifyConfig,
}) => {
  const sanitizedHtml = React.useMemo(() => {
    if (!htmlContent) return '';
    // IMPORTANT: Make sure DOMPurify is initialized for the current DOM environment
    // This is especially critical in SSR/SSG contexts or environments without a global DOM
    if (typeof window !== 'undefined' && window.DOMPurify) {
        return DOMPurify.sanitize(htmlContent, config);
    }
    // Fallback or throw error if DOMPurify is not available (e.g., during build)
    return ''; 
  }, [htmlContent, config]);

  return <Tag className={className} dangerouslySetInnerHTML={{ __html: sanitizedHtml }} />;
};

export default SanitizedText;
Enter fullscreen mode Exit fullscreen mode

Now, in your legacy components, instead of:

function OldProfile({ bio }) {
  // Yikes, raw HTML directly rendered
  return <div dangerouslySetInnerHTML={{ __html: bio }} />;
}
Enter fullscreen mode Exit fullscreen mode

You can refactor to:

import SanitizedText from './components/SanitizedText';

function RefactoredProfile({ bio }) {
  return <SanitizedText htmlContent={bio} className="user-bio" tagName="p" />;
}
Enter fullscreen mode Exit fullscreen mode

This immediately centralizes your sanitization logic, makes it testable, and provides a clear signal to developers about safe content rendering.

3. Sanitizing Input Fields (Even Before Display)

Sanitization isn't just for rendering. It's also vital for data going into your system. If you have an input field where users can paste rich text or even just plain text that might contain script tags, it's good practice to sanitize it before it even hits your React state or an API call.

import React, { useState } from 'react';
import DOMPurify from 'dompurify';

function CommentForm() {
  const [comment, setComment] = useState('');

  const handleCommentChange = (event: React.ChangeEvent<HTMLTextAreaElement>) => {
    const rawInput = event.target.value;
    // Sanitize before setting state, especially if this state
    // could be directly rendered or used in a way that bypasses React's escaping.
    const sanitizedInput = DOMPurify.sanitize(rawInput, { USE_PROFILES: { html: false } }); // Only allow plain text
    setComment(sanitizedInput);
  };

  const handleSubmit = (event: React.FormEvent) => {
    event.preventDefault();
    // At this point, `comment` state is already sanitized
    console.log("Submitting sanitized comment:", comment);
    // ... send to API ...
  };

  return (
    <form onSubmit={handleSubmit}>
      <textarea
        value={comment}
        onChange={handleCommentChange}
        placeholder="Leave your comment..."
      />
      <button type="submit">Post Comment</button>
      {/* Optional: Show a preview using SanitizedText if it's meant to be rich text */}
      {/* <SanitizedText htmlContent={comment} /> */}
    </form>
  );
}
Enter fullscreen mode Exit fullscreen mode

This is a proactive measure. While server-side will perform its own validation and sanitization, scrubbing it on the client offers immediate feedback and prevents bad data from even temporarily entering your application's state.

Insights from the Trenches

  • Context is King: The DOMPurify configuration is crucial. What's "safe" for a rich text editor (allowing <strong>, <a>, <em>) is vastly different from what's safe for a simple plain-text comment field (allowing almost nothing). Tailor your config object carefully.
  • Don't Roll Your Own: Seriously, don't try to write your own regex for HTML sanitization. It's an incredibly complex problem that security experts have dedicated years to. Use battle-tested libraries like DOMPurify or xss.
  • Test Your Sanitization: As a QA lead, I can't stress this enough. Write explicit tests for your SanitizedText component or utility functions. Include known XSS payloads, malformed HTML, and even "benign" but unwanted tags (like <style> or <script>). Your test suite should confirm that they are stripped or escaped correctly.

Common Pitfalls to Avoid

  1. Forgetting client-side: "The backend handles it." A classic. Yes, the backend should, but a layered defense is always better. Client-side sanitization improves UX by preventing malformed content from even showing up momentarily.
  2. Over-sanitizing: Stripping too much can frustrate users, especially in rich text editors. Balance security with functionality by fine-tuning your DOMPurify configuration.
  3. Applying sanitization too late: Waiting until just before dangerouslySetInnerHTML is fine for display, but for data being sent to the server, sanitize before state updates.
  4. Ignoring markdown: If your app supports markdown, make sure your markdown renderer is configured for safe output or that its output is then sanitized by DOMPurify. Libraries like remark-html often have options for this.

Wrapping Up

Mastering data sanitization in legacy React applications is a journey, not a destination. It requires vigilance, a proactive mindset, and a willingness to refactor older code. As a Lead QA Engineer, I've found that advocating for these practices, providing the right tools (like a robust SanitizedText component), and educating the team, drastically reduces security vulnerabilities and improves the overall robustness of our applications. It’s about being thoughtful, systematic, and always assuming the worst when it comes to user input. Stay safe out there!

> 🚀 Read on My Blog

Top comments (0)