Security in React Applications

A comprehensive guide to security in react applications with production examples and best practices.

The Threat Model for React Apps

Before writing any security code, you must understand what you're defending against. In React applications, the primary threats are Cross-Site Scripting (XSS), data injection, insecure direct object references (IDOR), and dependency vulnerabilities. XSS remains the most common: attackers inject malicious scripts via user input, URL parameters, or stored data. React's JSX escapes values by default, but dangerous patterns like dangerouslySetInnerHTML, eval, or direct DOM manipulation bypass this protection. Other vectors include prototype pollution through third-party libraries, open redirects via window.location, and sensitive data exposure in client-side bundles. A production app must assume the attacker controls the network, the browser, and any public API endpoint. This threat model drives every security decision: never trust user input, never expose secrets to the client, and always validate on the server.

// Example: XSS via dangerouslySetInnerHTML
const userComment = "<img src=x onerror=alert('XSS')>";

// Dangerous - never do this
function UnsafeComment() {
  return <div dangerouslySetInnerHTML={{ __html: userComment }} />;
}

// Safe - React escapes automatically
function SafeComment() {
  return <div>{userComment}</div>;
}

Input Validation and Sanitization

Input validation is your second line of defense. React apps receive input from forms, URL params, query strings, and WebSocket messages. Always validate on the client for UX, but never rely on it for security — server validation is mandatory. For client-side sanitization, use libraries like DOMPurify when you must render HTML. For URLs, validate against a whitelist of allowed protocols (https:// only) and domains. For form inputs, enforce type, length, and pattern constraints. Avoid using eval, new Function(), or setTimeout(string) — these are code injection vectors. Use a schema validator like Zod or Yup to enforce input shapes. Remember: validation is about rejecting bad data, not cleaning it. If you can't validate, reject.

import { z } from 'zod';

const CommentSchema = z.object({
  body: z.string().min(1).max(1000),
  userId: z.string().uuid(),
  postId: z.string().uuid(),
});

export function validateComment(data: unknown) {
  const result = CommentSchema.safeParse(data);
  if (!result.success) {
    throw new Error('Invalid input');
  }
  return result.data;
}

Secure Authentication and Session Management

Authentication in React apps typically uses JWTs stored in localStorage or cookies. localStorage is vulnerable to XSS: if an attacker injects a script, they can steal the token. Use httpOnly, Secure, SameSite=Strict cookies for session tokens. This prevents JavaScript access and mitigates XSS token theft. For refresh tokens, use a separate cookie with a shorter lifespan. Implement CSRF protection using SameSite cookies or custom headers. Never store secrets like API keys in the client bundle — use environment variables on the server and proxy requests. For OAuth flows, use the Authorization Code flow with PKCE, never the implicit flow. Logout should invalidate tokens server-side.

// Server-side cookie setting (Express example)
res.cookie('session', token, {
  httpOnly: true,
  secure: true,
  sameSite: 'strict',
  maxAge: 15 * 60 * 1000, // 15 minutes
});

// Client-side: no token in JS memory
// Use fetch with credentials: 'include'
fetch('/api/data', {
  credentials: 'include'
});

Protecting Against XSS in React

React's JSX escapes values, but there are edge cases. dangerouslySetInnerHTML is the obvious one, but also watch for: href attributes with javascript: URLs, onerror handlers in SVG, and style objects with user-controlled keys. Use npm audit and snyk to scan for vulnerable dependencies. For user-generated HTML, sanitize with DOMPurify on both client and server. Avoid using refs to directly manipulate the DOM — use React's declarative approach. For URL inputs, validate with new URL() and check protocol. For rich text editors, use libraries that output structured data (like Slate or TipTap) instead of raw HTML.

function SafeLink({ url, children }) {
  // Validate URL
  let parsed;
  try {
    parsed = new URL(url);
  } catch {
    return <span>{children}</span>;
  }
  if (parsed.protocol !== 'https:') {
    return <span>{children}</span>;
  }
  return <a href={url} rel="noopener noreferrer">{children}</a>;
}

Dependency Management and Supply Chain Security

Your React app is only as secure as its dependencies. The npm ecosystem has thousands of packages, many with known vulnerabilities. Use npm audit regularly and integrate Snyk or Dependabot into your CI pipeline. Pin exact versions in package.json to avoid surprise updates. Use package-lock.json to ensure reproducible builds. For critical packages, consider forking and auditing the code. Avoid packages with unnecessary permissions or that eval code. Use tools like socket.dev to check package behavior. Regularly prune unused dependencies — fewer packages mean fewer attack vectors.

{
  "dependencies": {
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "zod": "3.22.4"
  },
  "scripts": {
    "audit": "npm audit --audit-level=high"
  }
}

Secure API Communication

All communication between React and your backend must be over HTTPS. Use fetch with credentials: 'include' for cookie-based auth. For APIs, use a consistent pattern: validate responses, handle errors gracefully, and never expose internal error details to the client. Implement rate limiting and input validation on the server. Use Content Security Policy (CSP) headers to restrict what resources can be loaded. For GraphQL, use persisted queries to prevent injection. Avoid embedding API keys in the client — use a BFF (Backend for Frontend) pattern to proxy requests.

async function fetchData(url) {
  const response = await fetch(url, {
    credentials: 'include',
    headers: { 'Content-Type': 'application/json' }
  });
  if (!response.ok) {
    throw new Error('Request failed');
  }
  return response.json();
}

Content Security Policy (CSP)

CSP is a browser security mechanism that mitigates XSS and data injection attacks. It works by specifying which sources are allowed for scripts, styles, images, and other resources. For a React app, a strict CSP might allow only same-origin scripts and inline scripts with nonces. Use script-src 'self' and add nonces for inline scripts. Avoid 'unsafe-inline' and 'unsafe-eval'. For styles, use style-src 'self' and nonces. Report violations via report-uri or report-to. CSP can be tricky with React's development tools — test in production mode. Use csp-evaluator to check your policy.

// Express middleware example
app.use((req, res, next) => {
  res.setHeader(
    'Content-Security-Policy',
    "default-src 'self'; script-src 'self' 'nonce-abc123'; style-src 'self' 'nonce-abc123'; report-uri /csp-report"
  );
  next();
});

Secure State Management and Data Exposure

React state management libraries like Redux or Zustand store data in memory. Never store sensitive data like passwords, tokens, or PII in the client state. If you must display sensitive data, fetch it on demand and clear it when the component unmounts. Be cautious with browser extensions that can access the DOM and state. Use Object.freeze on state objects to prevent mutation. For server-side rendering, avoid embedding secrets in the initial state. Use environment variables for configuration, but remember they are bundled into the client code — only use them for non-sensitive values.

// Avoid storing sensitive data
const initialState = {
  user: {
    id: null,
    name: null,
    // Never store: password, ssn, token
  }
};

// Use Object.freeze to prevent accidental mutation
const store = createStore(reducer, Object.freeze(initialState));

Error Handling and Logging

Error handling is a security concern. Uncaught errors can leak stack traces, internal paths, and database schemas. Use error boundaries in React to catch rendering errors gracefully. Log errors on the server, not the client. Never display raw error messages to users. For API errors, return a generic message and log the details server-side. Use a centralized error tracking service like Sentry, but configure it to strip sensitive data. For development, use source maps but never deploy them to production.

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }
  static getDerivedStateFromError() {
    return { hasError: true };
  }
  componentDidCatch(error, info) {
    // Log to server, not console
    fetch('/api/log-error', {
      method: 'POST',
      body: JSON.stringify({ error: error.message }),
    });
  }
  render() {
    if (this.state.hasError) {
      return <h1>Something went wrong.</h1>;
    }
    return this.props.children;
  }
}

Security Testing and Auditing

Security is not a one-time effort. Integrate security testing into your CI/CD pipeline. Use static analysis tools like ESLint with security plugins (eslint-plugin-security, eslint-plugin-react-security). Run npm audit on every build. Use dynamic analysis tools like OWASP ZAP to scan for common vulnerabilities. Perform regular dependency audits with Snyk. For React-specific issues, check for missing key props, unsafe lifecycle methods, and improper use of refs. Penetration test your app before major releases. Keep a security checklist and review it during code reviews.

{
  "plugins": ["security", "react"],
  "rules": {
    "security/detect-object-injection": "error",
    "react/no-danger": "error",
    "react/no-unsafe": "error"
  }
}

Production Hardening Checklist

Before deploying, run through this checklist: 1) All API endpoints require authentication. 2) CSP headers are set with nonces. 3) No secrets in client bundle. 4) Dependencies are audited and up-to-date. 5) Error boundaries are in place. 6) HTTPS is enforced. 7) Cookies are httpOnly, Secure, SameSite. 8) Input validation exists on both client and server. 9) Logging is configured without sensitive data. 10) Source maps are not deployed. 11) Rate limiting is enabled on API. 12) Third-party scripts are reviewed. Use tools like securityheaders.com to check your headers. Regularly review your threat model as your app evolves.

# Run before deployment
npm audit --audit-level=high
npx eslint src/
npx snyk test
# Check CSP headers
curl -I https://yourapp.com | grep content-security-policy

Incident Response for React Apps

Even with the best defenses, incidents happen. Have a plan: 1) Detect: monitor logs and error reports for anomalies. 2) Contain: roll back the deployment, invalidate sessions, block malicious IPs. 3) Eradicate: patch the vulnerability, update dependencies. 4) Recover: restore from clean backup, redeploy. 5) Learn: conduct a post-mortem, update your threat model. For React apps, common incidents include XSS via a third-party script, leaked API keys in the bundle, or a compromised dependency. Practice incident response drills. Keep a runbook with steps for each scenario.

// Example: Invalidate all sessions
async function invalidateAllSessions() {
  await fetch('/api/admin/invalidate-sessions', {
    method: 'POST',
    credentials: 'include'
  });
  // Clear client state
  window.location.href = '/login';
}

Modern CSP: Nonce + strict-dynamic Pattern

Content Security Policy (CSP) is a critical defense against XSS attacks. For single-page applications (SPAs), the traditional whitelist-based CSP is often impractical due to dynamic script loading. The W3C-recommended approach uses nonces (cryptographic tokens) combined with the 'strict-dynamic' directive. This pattern allows only scripts with a valid nonce to execute, while 'strict-dynamic' automatically trusts scripts loaded by those approved scripts. This eliminates the need to maintain a whitelist of external domains. To implement, generate a unique nonce per request on the server and pass it to the React app. In your CSP header, use: script-src 'nonce-{random}' 'strict-dynamic' 'unsafe-inline' https:; object-src 'none'; base-uri 'none';. The 'unsafe-inline' is a fallback for older browsers; 'strict-dynamic' overrides it in modern ones. In React, add the nonce to script tags dynamically. For example, when loading a script: const script = document.createElement('script'); script.nonce = nonce; script.src = '...'; document.head.appendChild(script);. This pattern significantly reduces the attack surface by ensuring only server-approved scripts run.

// Server-side: generate nonce per request
const crypto = require('crypto');
const nonce = crypto.randomBytes(16).toString('base64');
res.setHeader('Content-Security-Policy', `script-src 'nonce-${nonce}' 'strict-dynamic' 'unsafe-inline' https:; object-src 'none'; base-uri 'none';`);

// Client-side: use nonce when dynamically adding scripts
const script = document.createElement('script');
script.nonce = nonce; // nonce passed from server (e.g., via meta tag or window.__NONCE__)
script.src = '/path/to/script.js';
document.head.appendChild(script);

CSP Report-Only Mode Deployment Strategy

Before enforcing a strict CSP, it's wise to test it using Report-Only mode. This mode sends violation reports without blocking resources, allowing you to identify and fix issues before going live. Set the header Content-Security-Policy-Report-Only instead of Content-Security-Policy. Configure a reporting endpoint using the report-uri or report-to directive. For example: Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report;. In React, you can set up a server endpoint to collect reports and log them. Use a monitoring service like Sentry or a custom logger. Analyze reports to find legitimate scripts that are being blocked and adjust your policy accordingly. Once confident, switch to enforce mode. This incremental approach prevents breaking your app in production. For SPAs, pay special attention to inline scripts and event handlers. Use the nonce pattern (see previous section) to allow necessary inline scripts. Report-Only mode is also useful for auditing third-party scripts and detecting potential XSS attempts.

// Server-side: set Report-Only header
res.setHeader('Content-Security-Policy-Report-Only', "default-src 'self'; script-src 'self'; report-uri /csp-report");

// Endpoint to collect reports (Express example)
app.post('/csp-report', (req, res) => {
  console.log('CSP Violation:', req.body);
  // Log to monitoring system
  res.status(204).end();
});

// In React, no changes needed; browser sends reports automatically

OWASP Top 10 for React Apps Mapping

The OWASP Top 10 is a standard awareness document for web application security. Mapping it to React helps prioritize risks. Here's a concise mapping:

// Example: Secure component with OWASP mitigations
import React, { useEffect } from 'react';
import { useNavigate } from 'react-router-dom';

function SecureComponent({ user }) {
  const navigate = useNavigate();

  useEffect(() => {
    // Broken Access Control: client-side guard
    if (!user || !user.role === 'admin') {
      navigate('/login');
    }
  }, [user, navigate]);

  // Injection: avoid dangerouslySetInnerHTML
  const safeContent = { __html: '' }; // sanitized server-side

  return <div dangerouslySetInnerHTML={safeContent} />; // only if sanitized
}