Javascript Typescript React Web Frontend Security

` where `userHtml` is from API/URL/storage. * “Sanitization” done with regexes, ad-hoc stripping, or incomplete allowlists. Detection hints: * Grep: `dangerouslySetInnerHTML`, `__html:` * Trace the origin of the HTML string (API/CMS/URL/localStorage). Fix: * Replace with safe rendering: * Render structured data as React elements/components instead of HTML strings. * If rich text is required, sanitize with DOMPurify (or equivalent) and render the sanitized output. * Add CSP; remove dangerous sinks where possible. Notes: * React explicitly warns that `dangerouslySetInnerHTML` is dangerous and can introduce XSS if misused. ([React][12]) * OWASP explicitly calls out React’s `dangerouslySetInnerHTML` without sanitization as a common framework “escape hatch” pitfall. ([OWASP Cheat Sheet Series][9]) * DOMPurify describes itself as an XSS sanitizer for HTML/SVG/MathML. ([GitHub][13]) --- ### REACT-XSS-002: Rely on React’s escaping-by-default behavior; do not bypass it Severity: High (when bypassed) Required: * MUST render untrusted strings via normal JSX interpolation (`{value}`) and React props, which are escaped by default. * MUST NOT build HTML strings from untrusted data and then inject them into the DOM via any means. * SHOULD treat any “escape hatch” as high risk and require review. Insecure patterns: * Converting untrusted text into HTML and injecting it: * `element.innerHTML = userValue` * `document.write(userValue)` * `insertAdjacentHTML(..., userValue)` Detection hints: * Grep for DOM sinks: `innerHTML`, `outerHTML`, `insertAdjacentHTML`, `document.write`, `DOMParser`, `createContextualFragment`. Fix: * Render text content through React (JSX) so it is escaped. * If you truly need HTML, sanitize and apply REACT-XSS-001 + REACT-TT-001. Notes: * React documentation (JSX) states that React DOM escapes values embedded in JSX before rendering to help prevent injection attacks. ([React][14]) --- ### REACT-DOM-001: Avoid DOM XSS injection sinks in React code (use safe alternatives) Severity: High Required: * MUST avoid direct DOM injection sinks, even outside React rendering, unless strongly controlled. * If a DOM sink is required: * MUST ensure inputs are trusted/validated/sanitized. * SHOULD enforce Trusted Types (REACT-TT-001). Insecure patterns: * `someEl.innerHTML = untrusted` * `document.write(untrusted)` * `new DOMParser().parseFromString(untrusted, 'text/html')` followed by insertion Detection hints: * Grep for: `innerHTML`, `outerHTML`, `document.write`, `DOMParser`, `Range().createContextualFragment`, `insertAdjacentHTML` Fix: * Prefer: * `textContent` for text insertion. * React rendering rather than manual DOM manipulation. * A vetted sanitizer for any required HTML parsing. Notes: * Trusted Types documentation defines HTML sinks like `Element.innerHTML` and `document.write()` as injection sinks that can execute script when given attacker-controlled input. ([MDN Web Docs][3]) * OWASP HTML5 guidance recommends using `textContent` instead of `innerHTML` for assigning untrusted data. ([OWASP Cheat Sheet Series][4]) --- ### REACT-URL-001: Validate and constrain untrusted URLs used in `href`, `src`, navigation, and redirects Severity: High Only when you can prove they are attacker controlled Required: * MUST treat any URL derived from untrusted input as dangerous. * MUST allowlist schemes and (when applicable) hosts: * Typically allow only `https:` (and maybe `http:` for localhost/dev) and relative URLs for in-app navigation. * MUST explicitly block `javascript:` and dangerous `data:` uses unless you have specialized validation and a clear use case. * SHOULD prefer same-site relative paths (e.g., `/settings`) over absolute URLs. * MUST validate “returnTo/next/redirect” parameters (see REACT-REDIRECT-001). Insecure patterns: * `...` (can be used for tracking / data exfil; also risky if used for scripts/iframes) * `window.location = next` * `navigate(next)` where `next` comes from query params without validation Detection hints: * Search for: * `href={`, `src={`, `window.location`, `location.href`, `window.open`, `navigate(`, `redirectTo`, `returnTo`, `next=` * Track whether the value is derived from URL/query/storage/API. Fix: * Implement a shared `safeUrl()` utility: * Parse with `new URL(value, base)` * Enforce scheme allowlist and host allowlist (or enforce same-origin) * For redirects: allow only relative paths (starting with `/`) or a strict allowlist of absolute origins. * Fall back to a safe default when validation fails. Notes: * OWASP explicitly notes React’s `dangerouslySetInnerHTML` risk and also states React cannot safely handle `javascript:` or `data:` URLs without specialized validation. ([OWASP Cheat Sheet Series][9]) --- ### REACT-MARKUP-001: Markdown / rich text rendering must be configured safely Severity: Medium Required: * MUST assume markdown/rich text can be attacker-controlled if it comes from users or CMS. * MUST ensure raw HTML is not rendered unless sanitized. * SHOULD prefer markdown renderers that: * Do not allow raw HTML by default, or * Can be configured to disallow raw HTML, or * Sanitize HTML output before rendering. Insecure patterns: * Markdown rendering with “raw HTML passthrough” enabled (e.g., options/plugins that allow HTML). * Rendering user-provided SVG/MathML/HTML inline without sanitization. Detection hints: * Search for common libraries and risky options: * `marked`, `markdown-it`, `react-markdown`, `rehype-raw`, `sanitize: false`, `allowDangerousHtml`, etc. * Look for `dangerouslySetInnerHTML` used with “markdown output”. Fix: * Disable raw HTML passthrough. * Sanitize output with a proven sanitizer (e.g., DOMPurify) before rendering. Notes: * OWASP XSS guidance emphasizes that framework escape hatches require output encoding and/or HTML sanitization. ([OWASP Cheat Sheet Series][9]) --- ### REACT-TT-001: Use Trusted Types (with CSP) to harden DOM XSS sinks where feasible Severity: Low Required: * SHOULD consider enabling Trusted Types in report-only mode first, then enforce once violations are addressed. * SHOULD centralize Trusted Types policies and treat them as high-risk code requiring review. * MUST NOT create permissive policies that simply “pass through” untrusted strings. Insecure patterns: * A Trusted Types policy that returns the raw string without sanitization for HTML sinks. * Many scattered policies across the codebase (hard to audit). Detection hints: * Search for: * `trustedTypes.createPolicy` * CSP directives: `require-trusted-types-for`, `trusted-types` * Search for remaining DOM sinks (REACT-DOM-001). Fix: * Implement a small number of tightly scoped policies: * HTML policy uses sanitizer (DOMPurify or equivalent). * Script URL policy uses strict allowlists. * Run in report-only mode, fix violations, then enforce. Notes: * MDN describes Trusted Types as a way to ensure input is transformed (commonly sanitized) before being passed to injection sinks, and highlights HTML sinks (`innerHTML`, `document.write`) and JS URL sinks (`script.src`). ([MDN Web Docs][3]) * The W3C Trusted Types spec frames this as reducing DOM XSS risk by locking down sinks to typed values created by reviewed policies. ([W3C][15]) --- ### REACT-CSP-001: Deploy and maintain a CSP as defense-in-depth (especially when rendering untrusted content) Severity: Medium to High Required: * SHOULD deploy CSP in production; MUST do so for apps that render untrusted content or integrate third-party scripts. * SHOULD avoid `unsafe-inline` and `unsafe-eval` when possible. * SHOULD use CSP nonces/hashes for inline scripts if needed, and keep policy realistic. * SHOULD use CSP to require/encourage SRI where appropriate. Insecure patterns: * No CSP at all on the app shell (SPA entry HTML). * CSP that relies on `unsafe-inline`/`unsafe-eval` broadly without justification. * `script-src *` or overly broad sources. Detection hints: * Look for CSP configuration: * Server/CDN config, headers in `index.html` responses, or framework config. * If absent in repo, mark as “verify at edge”. Fix: * Add CSP via HTTP response headers (preferred). * Start with report-only to reduce breakage, then enforce. Notes: * OWASP describes CSP as “defense in depth” against XSS and notes it can help enforce SRI even on static sites, but should not be the only defense. ([OWASP Cheat Sheet Series][2]) --- ### REACT-SRI-001: Use Subresource Integrity (SRI) for third-party scripts and styles (or self-host) Severity: Low Required: * MUST treat third-party JS as equivalent to running arbitrary code in your origin. * If loading from a CDN or third party: * SHOULD use SRI (`integrity=...`) and `crossorigin` where applicable. * SHOULD pin exact versions (avoid “latest” URLs). * SHOULD prefer self-hosting for critical code. Insecure patterns: * `` with no integrity. * Tag managers that dynamically load arbitrary scripts without governance. Detection hints: * Search in `public/index.html`, templates, or SSR wrappers for: * `<script src=`, ` { eval(e.data) })` * `element.innerHTML = e.data` Detection hints: * Search: `postMessage(`, `addEventListener('message'` * Check for origin checks and safe handling. Fix: * Add strict origin allowlists and schema validation (e.g., zod). * Treat message payload strictly as data; render safely via React. Notes: * OWASP HTML5 guidance recommends specifying expected origin for `postMessage`, checking sender origin, validating data, and avoiding eval/innerHTML with message content. ([OWASP Cheat Sheet Series][4]) --- ### REACT-FILE-001: File uploads and previews must not create client-side active content vulnerabilities Severity: Medium (can be High if stored-XSS possible) Required: * MUST treat user-uploaded files and previews as potentially malicious. * MUST NOT render uploaded HTML/SVG/other active content inline unless sanitized and explicitly required. * SHOULD validate file types client-side for UX, but MUST rely on server-side validation for security. Insecure patterns: * Rendering user-uploaded HTML as content. * Inline rendering of untrusted SVG/HTML via `dangerouslySetInnerHTML` or `` without sanitization. Detection hints: * Search for upload components and preview logic: * `input type="file"`, `FileReader`, `URL.createObjectURL`, ``, `