How to Secure Error Boundaries in React

React Error Boundaries are essential for catching runtime errors in component trees, preventing entire application crashes, and displaying fallback User Interfaces (UIs). However, if left unsecured, they can expose sensitive system architecture, leak Personally Identifiable Information (PII) through stack traces, or become vectors for Cross-Site Scripting (XSS) and Denial of Service (DoS) attacks. Securing your Error Boundaries requires a combination of strict environment-based rendering, sanitized logging, secure fallback UIs, and loop prevention mechanisms.

Prevent Information Disclosure in Production

The most common security vulnerability associated with Error Boundaries is the accidental exposure of detailed stack traces, database queries, or internal API paths to end-users.

• Strip Stack Traces: Ensure that raw error objects (error.stack or error.message) are never rendered directly in the production UI.
• Environment Checks: Use environment variables to determine what level of detail to display. Show detailed errors only in local development environments.

// Inside your Error Boundary's render method
render() {
  if (this.state.hasError) {
    const isDevelopment = process.env.NODE_ENV === 'development';
    return (
      <div role="alert">
        <h2>Something went wrong.</h2>
        {isDevelopment && (
          <pre>{this.state.error && this.state.error.toString()}</pre>
        )}
      </div>
    );
  }
  return this.props.children;
}

Sanitize and Secure Error Logging

Error Boundaries typically log errors to external monitoring services (like Sentry, LogRocket, or Datadog) using the componentDidCatch(error, errorInfo) lifecycle method. If not handled carefully, this process can transmit sensitive user data to third-party servers.

• Strip PII and Secrets: Before sending error payloads to your logging server, run a sanitization script to scrub authentication tokens, credit card numbers, passwords, and PII from the state, URL parameters, and error messages.
• Use Secure Transports: Ensure your logging SDKs are configured to transmit data exclusively over HTTPS and utilize secure API keys restricted to ingestion-only permissions.

Avoid Cross-Site Scripting (XSS) in Fallback UIs

If your fallback UI dynamically renders parts of the error message or context gathered from the URL or user input, attackers could exploit this to inject malicious scripts.

• Avoid dangerouslySetInnerHTML: Never use dangerouslySetInnerHTML within fallback UIs to render error descriptions.
• Sanitize Dynamic Text: Treat all error-related strings as untrusted user input. If you must display a dynamic error message, sanitize it using libraries like DOMPurify before rendering.

Prevent Infinite Rendering Loops (Denial of Service)

A malfunctioning error recovery mechanism can cause infinite rendering loops, leading to browser crashes and client-side Denial of Service. This often happens when an Error Boundary attempts to recover by automatically retrying a failed operation or resetting state, only to trigger the same error immediately.

• Limit Retry Attempts: Implement a counter to limit automatic retries. If the error persists after a set number of attempts (e.g., 3 times), disable automatic retries and force the user to manually trigger a page refresh or navigate away.
• Time-to-Live (TTL) Resets: Use a timestamp to ensure that state resets can only occur after a safe interval, preventing rapid, repeated crash cycles.

Secure Server-Side Rendering (SSR) Error Handling

If you are using Server-Side Rendering (SSR) frameworks like Next.js or Remix, errors caught during server-side rendering can leak server-side file paths, environment variables, or database schemas in the HTML payload sent to the client.

• Intercept Server Errors: Configure your server framework to intercept errors before they reach the document serialization phase.
• Replace Server Errors with Generic IDs: Replace detailed server-side error messages with a generic error code or a unique incident ID (e.g., “Error Code: 500-A91”). The user can reference this ID when contacting support, while developers can look up the corresponding secure, unexposed server logs.