# 1567 Javascript Typescript React Web Frontend Security 1927ce33

> React (JavaScript/TypeScript) Web Security Spec (React 19.x, TypeScript 5.x)

- Skill: `tools-only/1567-javascript-typescript-react-web-frontend-security-1927c` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add tools-only/1567-javascript-typescript-react-web-frontend-security-1927c`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/1567-javascript-typescript-react-web-frontend-security-1927c/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: tools-only (https://skillmd.com/u/tools-only)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/tools-only/1567-javascript-typescript-react-web-frontend-security-1927c

---

# React (JavaScript/TypeScript) Web Security Spec (React 19.x, TypeScript 5.x)

This document is designed as a **security spec** that supports:

1. **Secure-by-default code generation** for new React code.
2. **Security review / vulnerability hunting** in existing React code (passive “notice issues while working” and active “scan the repo and report findings”).

It is intentionally written as a set of **normative requirements** (“MUST/SHOULD/MAY”) plus **audit rules** (what bad patterns look like, how to detect them, and how to fix/mitigate them).

---

## 0) Safety, boundaries, and anti-abuse constraints (MUST FOLLOW)

- MUST NOT request, output, log, or commit secrets (API keys, OAuth client secrets, private keys, session cookies, JWTs, signing keys).
  - Frontend note: anything shipped to the browser is observable by end users and attackers (view-source, devtools, proxies); never treat client code or “env vars in the bundle” as secret. ([create-react-app.dev][1])

- MUST NOT “fix” security by disabling protections (e.g., turning off CSP to “make it work”, adding `unsafe-inline`/`unsafe-eval` without a documented, constrained plan, disabling CSRF protections when using cookies, widening CORS, skipping sanitization, or “temporary” bypasses that ship). ([OWASP Cheat Sheet Series][2])
- MUST provide **evidence-based findings** during audits: cite file paths, code snippets, and configuration values that justify the claim.
- MUST treat uncertainty honestly: if a protection might exist in infra (CDN/WAF/reverse proxy), report it as “not visible in app code; verify via runtime headers / edge config”.
- MUST assume any data that crosses a trust boundary (URL, storage, network, postMessage, third-party scripts) can be attacker-influenced unless proven otherwise (see §2.1).

---

## 1) Operating modes

### 1.1 Generation mode (default)

When asked to write new React code or modify existing code:

- MUST follow every **MUST** requirement in this spec.
- SHOULD follow every **SHOULD** requirement unless the user explicitly says otherwise.
- MUST prefer safe-by-default APIs and proven libraries over custom security code.
- MUST avoid introducing new risky sinks (raw HTML insertion, direct DOM sinks like `innerHTML`, dynamic code execution, untrusted redirects/navigation, third‑party script injection, unsafe token storage, etc.). ([MDN Web Docs][3])

### 1.2 Passive review mode (always on while editing)

While working anywhere in a React repo (even if the user did not ask for a security scan):

- MUST “notice” violations of this spec in touched/nearby code.
- SHOULD mention issues as they come up, with a brief explanation + safe fix.

### 1.3 Active audit mode (explicit scan request)

When the user asks to “scan”, “audit”, or “hunt for vulns”:

- MUST systematically search the codebase for violations of this spec.
- MUST output findings in a structured format (see §2.3).

Recommended audit order:

1. App entrypoints, build tooling (Vite/Webpack/CRA/Next), deployment configs, CDN/static hosting config.
2. Secrets & configuration exposure (env vars, runtime config injection, source maps).
3. Rendering of untrusted data (XSS/DOM XSS), especially `dangerouslySetInnerHTML`, markdown/HTML renderers, URL attributes.
4. Direct DOM usage and dangerous JS execution (`innerHTML`, `eval`, `new Function`, `document.write`, etc.).
5. Auth & session patterns (token storage, cookies, CSRF interactions, OAuth flows).
6. Network layer (axios/fetch wrappers, dynamic base URLs, credentialed requests, data exfil risks).
7. Navigation & redirect handling (open redirects, `window.location`, `target=_blank`, `window.open`).
8. Third-party scripts/tags/analytics and integrity controls (CSP, SRI).
9. Service worker/PWA behavior (HTTPS, caching rules, update strategy).
10. Security headers posture (CSP, clickjacking, nosniff, referrer policy) in app or at the edge. ([OWASP Cheat Sheet Series][2])

---

## 2) Definitions and review guidance

### 2.1 Untrusted input (treat as attacker-controlled unless proven otherwise)

Examples include:

- URL-derived data: `window.location`, query params, hash fragments, route params.
- Any data from browser storage: `localStorage`, `sessionStorage`, `IndexedDB` (including data previously written by the app—because XSS or extensions can tamper with it). ([OWASP Cheat Sheet Series][4])
- Any data from cross-window messaging: `window.postMessage` payloads. ([OWASP Cheat Sheet Series][4])
- Any data from remote APIs, webhooks proxied to the client, GraphQL responses, CMS content, feature flag services.
- Any persisted user content (profiles, comments, rich text, markdown) rendered in the UI.
- Any data produced by third-party scripts or tag managers (treat as untrusted unless strongly controlled). ([OWASP Cheat Sheet Series][5])

### 2.2 State-changing request (frontend perspective)

A request is state-changing if it can create/update/delete data, change auth/session state, trigger side effects (purchase, email send, webhook), or initiate privileged actions.

Frontend-specific note:

- State changes are often triggered by `fetch/axios` calls or form submissions. If authentication is cookie-based, these calls can be CSRF-relevant (§4 REACT-CSRF-001). ([OWASP Cheat Sheet Series][6])

### 2.3 Required audit finding format

For each issue found, output:

- Rule ID:
- Severity: Critical / High / Medium / Low
- Location: file path + component/function + line(s)
- Evidence: the exact code/config snippet
- Impact: what could go wrong, who can exploit it
- Fix: safe change (prefer minimal diff)
- Mitigation: defense-in-depth if immediate fix is hard
- False positive notes: what to verify if uncertain

---

## 3) Secure baseline: minimum production configuration (MUST in production)

This is the smallest “production baseline” that prevents common React frontend misconfigurations.

### 3.1 Production build and configuration hygiene (MUST)

- MUST ship a production build (minified, no dev-only overlays/tools, correct mode flags).
- MUST ensure build-time configuration does not embed secrets into the shipped JS/HTML/CSS. Build-time “environment variables” are not secret; treat them as public. ([create-react-app.dev][1])
- SHOULD treat source maps as sensitive operational artifacts:
  - Either don’t publish them publicly, or publish them only where intended (e.g., behind auth or to an error-reporting provider), because they can reveal code structure and internal URLs.

### 3.2 Browser-enforced protections (SHOULD, but baseline expectation for modern apps)

- SHOULD deploy a CSP as defense-in-depth against XSS, and keep it compatible with your React build (avoid `unsafe-inline` and `unsafe-eval` unless strictly necessary and documented). ([OWASP Cheat Sheet Series][2])
- SHOULD use Subresource Integrity (SRI) for any third-party script/style loaded from a CDN (or self-host instead). ([MDN Web Docs][7])
- SHOULD enable clickjacking defenses via `frame-ancestors` (CSP) and/or `X-Frame-Options`, unless embedding is an explicit product requirement. ([MDN Web Docs][8])

### 3.3 High-risk features baseline (MUST if used)

- If rendering any user-provided HTML/markdown/rich text:
  - MUST sanitize before insertion and avoid raw DOM sinks. ([OWASP Cheat Sheet Series][9])

- If using service workers / PWA:
  - MUST serve over HTTPS and implement a safe caching/update strategy (service workers are powerful request/response proxies). ([MDN Web Docs][10])

---

## 4) Rules (generation + audit)

Each rule contains: required practice, insecure patterns, detection hints, and remediation.

### REACT-CONFIG-001: Never embed secrets in the client bundle (env vars are public)

Severity: Critical (if secrets exposed)

Required:

- MUST NOT place secrets in React code, in `public/` assets, or in build-time environment variables intended for client consumption.
- MUST assume any value available to the React app at runtime can be extracted by an attacker.

Insecure patterns:

- Using build-time env vars for secrets:
  - `process.env.REACT_APP_*` containing private keys or credentials.
  - `import.meta.env.VITE_*` containing secrets.

- Hard-coded secrets in JS/TS, `.env` committed, or secrets in `public/config.json` served to all users.

Detection hints:

- Search for:
  - `REACT_APP_`, `VITE_`, `NEXT_PUBLIC_`, `process.env.`, `import.meta.env.`
  - `apiKey`, `secret`, `token`, `private`, `password`, `client_secret`

- Inspect `public/` for runtime config JSON.

Fix:

- Move secrets server-side (API, BFF, serverless function).
- Use a backend to mint short-lived, scoped tokens if the browser needs to call third-party APIs.

Notes:

- CRA explicitly warns not to store secrets and notes env vars are embedded into the build and visible to anyone inspecting files. ([create-react-app.dev][1])
- Vite explicitly notes that variables exposed to client code end up in the client bundle and should not contain sensitive info. ([vitejs][11])

---

### REACT-XSS-001: Do not use `dangerouslySetInnerHTML` with untrusted content (sanitize or avoid)

Severity: High (Only if you can prove attacker-controlled HTML reaches it)

Required:

- MUST avoid `dangerouslySetInnerHTML` unless absolutely necessary.
- If it must be used:
  - MUST sanitize untrusted HTML with a proven sanitizer (e.g., DOMPurify) and an allowlist-oriented configuration.
  - MUST keep the sanitization logic centralized and heavily reviewed.
  - SHOULD add a CSP and consider Trusted Types (see REACT-TT-001).

Insecure patterns:

- `<div dangerouslySetInnerHTML={{ __html: userHtml }} />` 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:

- `<img src={userProvidedUrl}>...` (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:

- `<script src="https://cdn.example.com/lib/latest.js"></script>` 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=`, `<link rel="stylesheet" href=`
  - Tag manager snippets (GTM, Segment, etc.)

- Identify scripts loaded dynamically in runtime JS.

Fix:

- Add SRI hashes for stable third-party assets or self-host.
- Apply governance controls for tag managers (see REACT-3P-001).

Notes:

- MDN describes SRI as a security feature enabling browsers to verify fetched resources (e.g., from a CDN) haven’t been manipulated by checking a cryptographic hash. ([MDN Web Docs][7])
- OWASP CSP guidance notes CSP can enforce SRI and is useful even on static sites. ([OWASP Cheat Sheet Series][2])

---

### REACT-3P-001: Third-party JavaScript and tag managers must be minimized and governed

Severity: High

Required:

- MUST minimize third-party scripts and treat each as a supply-chain risk.
- MUST know exactly what third-party JS executes in your origin and why.
- SHOULD implement governance:
  - Review and pin versions (or mirror in-house).
  - Restrict data access (data-layer approach).
  - Use SRI and CSP; consider sandboxing untrusted UI in iframes where possible.

Insecure patterns:

- Unreviewed analytics/ads scripts running with full access to DOM, cookies, storage, and user data.
- Tag managers that can be changed by non-engineering roles with no change control.

Detection hints:

- Search for common vendor snippets in HTML/JS:
  - GTM, Segment, Hotjar, FullStory, etc.

- Look for dynamic script insertion:
  - `document.createElement('script')`, `.src = ...`, `.appendChild(script)`

Fix:

- Reduce to only necessary vendors.
- Where feasible:
  - Self-host or mirror scripts.
  - Use SRI.
  - Limit data exposure via a controlled data layer.

Notes:

- OWASP notes third-party JS server compromise can inject malicious JS, and highlights risks like arbitrary code execution and disclosure of sensitive info to third parties. ([OWASP Cheat Sheet Series][5])

---

### REACT-AUTH-001: Token and session handling must be resilient to XSS (avoid sensitive storage in Web Storage)

Severity: Medium

Required:

- SHOULD avoid storing session identifiers or long-lived tokens in `localStorage` (and generally in Web Storage) because XSS can exfiltrate them.
- If tokens must exist client-side:
  - SHOULD prefer in-memory storage with short lifetimes and refresh mechanisms.
  - MUST scope and rotate tokens; avoid long-lived bearer tokens in persistent storage.

- SHOULD prefer HTTPOnly cookies for session tokens when possible (requires CSRF strategy: see REACT-CSRF-001).

Insecure patterns:

- `localStorage.setItem('token', ...)` / `sessionStorage.setItem('token', ...)` for auth tokens.
- Persisting refresh tokens in `localStorage`.
- Treating data from Web Storage as trusted.

Detection hints:

- Grep for: `localStorage.`, `sessionStorage.`, `setItem(`, `getItem(`, `token`, `jwt`, `refresh`
- Search auth code for “remember me” storing tokens persistently.

Fix:

- Move to HTTPOnly cookies (server change) + CSRF protections, or use short-lived in-memory tokens.
- Reduce token scope and lifetime.

Notes:

- OWASP HTML5 guidance recommends avoiding sensitive info and session identifiers in local storage and warns that a single XSS can steal all data in Web Storage. ([OWASP Cheat Sheet Series][4])
- OAuth browser-based apps guidance discusses that tokens stored in persistent browser storage like localStorage can be accessible to malicious JS (e.g., via XSS). ([IETF Datatracker][16])

---

### REACT-CSRF-001: Cookie-authenticated, state-changing requests MUST be CSRF-protected

Severity: High

NOTE: If the application does not use cookie based auth (using Authentication header for example), then CSRF is not a concern.

Required:

- If the app relies on cookies for authentication:
  - MUST protect state-changing requests (POST/PUT/PATCH/DELETE) against CSRF.
  - SHOULD include a CSRF token mechanism (synchronizer token or double-submit cookie) or other robust pattern appropriate to the backend.
  - SHOULD use SameSite cookies as defense-in-depth, not as the sole defense.

Insecure patterns:

- `fetch('/api/transfer', { method: 'POST', credentials: 'include' })` with no CSRF token/header, relying only on cookies.
- Using GET for state-changing operations.

Detection hints:

- Enumerate state-changing network calls and check:
  - Is `credentials: 'include'` or `withCredentials: true` used?
  - Is a CSRF token header included (e.g., `X-CSRF-Token`)?

- Search for “csrf” utilities; if absent, treat as suspicious.

Fix:

- Add CSRF token flow:
  - Fetch token from a safe endpoint and attach to state-changing requests.
  - Validate server-side.

- Keep SameSite cookies and Origin/Referer validation as defense-in-depth.

Notes:

- OWASP CSRF guidance explains SameSite behavior (Lax/Strict/None) as a defense-in-depth technique and why Lax is often the usability/security balance, but it is not a complete substitute for CSRF protections. ([OWASP Cheat Sheet Series][6])

---

### REACT-AUTHZ-001: Do not rely on frontend-only authorization

Severity: High (only if used as primary protection)

Required:

- MUST treat all frontend authorization checks as UX only.
- MUST enforce authorization on the server for any protected resource or action.

Insecure patterns:

- “Protected” actions hidden in UI but callable by API without server checks.
- Client checks like `if (user.isAdmin) { showAdminPanel(); }` with no server-side enforcement.

Detection hints:

- Look for UI gating around sensitive actions and verify server endpoints enforce authorization.
- In a frontend-only audit, report as “client checks are not security; verify backend”.

Fix:

- Add/confirm server-side authorization checks.
- Keep frontend gating only as convenience.

Notes:

- This is a general web app security property; React cannot protect server resources by itself.

---

### REACT-NET-001: Prevent data exfiltration and credential leakage via dynamic outbound requests

Severity: Medium to High

Required:

- MUST avoid making authenticated requests to attacker-controlled origins.
- SHOULD avoid allowing user input to control request destination (scheme/host/port).
- SHOULD centralize network clients (fetch/axios) with:
  - fixed `baseURL` (or strict allowlist),
  - strict handling of redirects,
  - explicit `credentials` usage.

Insecure patterns:

- `fetch(userProvidedUrl, { credentials: 'include' })`
- `axios.create({ baseURL: userProvidedBase })`
- “URL fetch/preview” features in the client that hit arbitrary domains with sensitive headers.

Detection hints:

- Search for `fetch(` / `axios(` where the first argument or `baseURL` is derived from:
  - query params, localStorage, API responses, postMessage

- Search for `credentials: 'include'`, `withCredentials: true`.

Fix:

- Enforce destination allowlists; disallow cross-origin requests unless explicitly required.
- Strip credentials/Authorization headers for any non-allowlisted destination.

Notes:

- Even if the browser limits some cross-origin behavior, leaking tokens/headers to untrusted endpoints is still a common failure mode.

---

### REACT-REDIRECT-001: Prevent open redirects and untrusted navigation

Severity: Medium

Required:

- MUST validate redirect/navigation targets derived from untrusted input (`next`, `returnTo`, `redirect`).
- SHOULD only allow same-site relative paths, or a strict allowlist of trusted origins for absolute URLs.

Insecure patterns:

- `window.location.href = new URLSearchParams(location.search).get('next')`
- `navigate(next)` where `next` comes from query params.

Detection hints:

- Search for: `next`, `returnTo`, `redirect`, `window.location`, `navigate(`
- Trace origin of the redirect target.

Fix:

- Only allow relative paths (`/^\/[^\s]*$/`) or allowlisted origins.
- Fall back to a safe default (e.g., `/`) when invalid.

Notes:

- Open redirects are frequently used in phishing and can undermine SSO/OAuth flows.

---

### REACT-SW-001: Service workers are high-privilege; require HTTPS and safe caching/update rules

Severity: Medium

Required:

- MUST serve service workers over HTTPS (except `localhost` dev), and deploy only in secure contexts.
- MUST avoid caching sensitive authenticated API responses unless explicitly designed and threat-modeled.
- SHOULD implement safe update strategy (prompt reload, versioned caches, remove old caches on activate).

Insecure patterns:

- Registering a service worker for an authenticated app and caching “everything” indiscriminately.
- Long-lived caches containing PII or user-specific content shared across accounts.

Detection hints:

- Search for:
  - `navigator.serviceWorker.register`
  - `workbox`, `precacheAndRoute`, custom `fetch` handlers

- Inspect caching patterns (`caches.open`, `cache.put`, `respondWith`).

Fix:

- Restrict caching to static assets only (JS/CSS/images) unless you have a designed offline model.
- Ensure cache keys are user-scoped if user-specific data must be cached.
- Provide a clear update mechanism.

Notes:

- MDN notes service workers require HTTPS for security reasons and act like a proxy for requests/responses. ([MDN Web Docs][10])
- “Secure contexts” exist to prevent MITM attackers from accessing powerful APIs; service workers are an example of such a powerful feature. ([MDN Web Docs][18])

---

### REACT-HEADERS-001: Ensure essential security headers are set for the React app shell (app or edge)

Severity: Medium

Required (typical SPA served from an origin):

- SHOULD set:
  - CSP (`Content-Security-Policy`)
  - `X-Content-Type-Options: nosniff`
  - Clickjacking protection (`frame-ancestors` in CSP and/or `X-Frame-Options`)
  - `Referrer-Policy`
  - `Permissions-Policy` as appropriate

- MUST ensure these are set somewhere (CDN/edge/server), even if not in repo.

Insecure patterns:

- No security headers anywhere (app or edge).
- CSP missing on apps that render untrusted content or use third-party scripts.

Detection hints:

- Check server/CDN config in repo (nginx, Cloudflare, Vercel config, etc.).
- If absent, flag as “verify at runtime/edge”.

Fix:

- Set headers centrally at the edge.
- Keep CSP realistic and iterative (report-only → enforce).

Notes:

- MDN clickjacking guidance discusses defenses including `X-Frame-Options` and CSP `frame-ancestors`. ([MDN Web Docs][8])
- OWASP CSP guidance explains delivery via response headers and recommends headers as the preferred mechanism. ([OWASP Cheat Sheet Series][2])

---

### REACT-POSTMSG-001: `postMessage` must validate origin and treat payload as untrusted data

Severity: Medium to High (depends on what messages can do)

Required:

- MUST specify exact `targetOrigin` when sending messages (not `*`) unless there is a strict reason.
- MUST validate `event.origin` on receipt and validate message shape.
- MUST NOT evaluate message data as code or insert it into the DOM as HTML.

Insecure patterns:

- `window.postMessage(data, '*')` to unknown targets.
- Receiving:
  - `window.addEventListener('message', (e) => { 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 `<iframe srcdoc=...>` without sanitization.

Detection hints:

- Search for upload components and preview logic:
  - `input type="file"`, `FileReader`, `URL.createObjectURL`, `<iframe>`, `<object>`, `<embed>`.

- Trace where uploaded content is later displayed.

Fix:

- Restrict accepted types, sanitize where needed, and prefer download/attachment flows for risky types.
- Ensure server enforces the real policy (type checking, renaming, scanning, storing outside webroot).

Notes:

- OWASP file upload guidance highlights allowlisting extensions, validating file type, generating filenames, limiting size, storing outside webroot, and considering “client-side active content (XSS, CSRF, etc.)” when files are publicly retrievable. ([OWASP Cheat Sheet Series][19])

---

### REACT-SUPPLY-001: Dependency and supply-chain hygiene (frontend + build tooling)

Severity: Low

Required:

- MUST use a lockfile and enforce reproducible installs in CI.
- SHOULD regularly audit dependencies and respond quickly to advisories for:
  - React, react-dom, router libs, build tooling (Vite/Webpack), sanitizers, auth libs, etc.

- SHOULD reduce exposure to install-time script attacks and typosquatting risk.

Audit focus:

- CI should use `npm ci` (or Yarn frozen lockfile / pnpm equivalent) to prevent drift.
- Use vulnerability scanning (`npm audit`, GitHub Dependabot/alerts, etc.).

Insecure patterns:

- No lockfile or lockfile ignored in CI.
- `npm install` in CI producing non-reproducible builds.
- Unpinned or unreviewed high-risk deps; sudden major updates without review.
- Blindly running install scripts from third-party packages.

Detection hints:

- Check for lockfiles: `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`.
- Check CI scripts for `npm install` vs `npm ci`.
- Search for `postinstall` scripts and suspicious build steps.

Fix:

- Use lockfile and enforce it in CI (e.g., `npm ci`).
- Run audits regularly; pin/upgrade responsibly.
- Consider restricting install scripts where feasible.

Notes:

- npm docs describe `npm audit` as submitting the project dependency tree to the registry to receive a report of known vulnerabilities and (optionally) applying remediations via `npm audit fix`, while noting some vulns require manual review. ([npm Docs][20])
- npm docs describe `npm ci` as intended for automated/CI environments, requiring an existing lockfile and failing if `package.json` and lockfile do not match. ([npm Docs][21])
- OWASP NPM security guidance recommends enforcing the lockfile and explicitly calls out `npm ci` / `yarn install --frozen-lockfile` to abort on inconsistencies, and highlights the risk of install-time scripts and the option to use `--ignore-scripts` to reduce attack surface. ([OWASP Cheat Sheet Series][22])

---

## 5) Practical scanning heuristics (how to “hunt”)

When actively scanning, use these high-signal patterns:

- Raw HTML / XSS escape hatches:
  - `dangerouslySetInnerHTML`, `__html:`
  - Markdown HTML passthrough flags: `rehype-raw`, `allowDangerousHtml`, `sanitize: false`

- DOM XSS sinks:
  - `innerHTML`, `outerHTML`, `insertAdjacentHTML`, `document.write`, `DOMParser`, `createContextualFragment`

- Dangerous JS execution:
  - `eval(`, `new Function(`, `setTimeout("`, `setInterval("`

- Untrusted URL injection / navigation:
  - `href={` / `src={` with untrusted values
  - `window.location`, `location.href`, `window.open`, `navigate(`
  - Query params: `next`, `returnTo`, `redirect`

- Token/session risk:
  - `localStorage.setItem`, `sessionStorage.setItem`, `getItem(` with `token`, `jwt`, `refresh`

- Cookie/CSRF coupling:
  - `credentials: 'include'`, `withCredentials: true` on state-changing requests without CSRF headers

- Third-party scripts:
  - `<script src=...>` in `public/index.html`
  - Tag manager snippets and dynamic script insertion

- Service workers:
  - `navigator.serviceWorker.register`, Workbox usage, custom `fetch` handlers

- postMessage:
  - `postMessage(` with `*`, missing `event.origin` checks

- Supply chain:
  - Missing lockfile, CI uses `npm install`, no audit step, risky postinstall scripts

Always try to confirm:

- data origin (untrusted vs trusted)
- sink type (React escape hatch vs DOM sink vs navigation vs storage)
- protective controls present (sanitization, allowlists, CSP/Trusted Types, CSRF tokens, headers, governance)

---

## 6) Sources (accessed 2026-01-26)

Primary React documentation:

- React 19 stable announcement — `https://react.dev/blog/2024/12/05/react-19` ([React][23])
- React DOM docs: `dangerouslySetInnerHTML` warning — `https://react.dev/reference/react-dom/components/common#dangerouslysetting-the-inner-html` ([React][12])
- React (legacy) JSX escaping statement — `https://legacy.reactjs.org/docs/introducing-jsx.html` ([React][14])

OWASP Cheat Sheet Series:

- Cross Site Scripting Prevention (framework escape hatches; React `dangerouslySetInnerHTML`; URL validation notes) — `https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html` ([OWASP Cheat Sheet Series][9])
- Content Security Policy — `https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html` ([OWASP Cheat Sheet Series][2])
- Cross-Site Request Forgery Prevention — `https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html` ([OWASP Cheat Sheet Series][6])
- HTML5 Security (Web Storage, postMessage, tabnabbing, sandboxed frames) — `https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html` ([OWASP Cheat Sheet Series][4])
- Third Party JavaScript Management — `https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html` ([OWASP Cheat Sheet Series][5])
- File Upload — `https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html` ([OWASP Cheat Sheet Series][19])
- NPM Security best practices — `https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html` ([OWASP Cheat Sheet Series][22])

Browser / platform references (MDN, W3C):

- Trusted Types API — `https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API` ([MDN Web Docs][3])
- W3C Trusted Types spec — `https://www.w3.org/TR/trusted-types/` ([W3C][15])
- Subresource Integrity — `https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity` ([MDN Web Docs][7])
- Clickjacking defenses overview — `https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Clickjacking` ([MDN Web Docs][8])
- Using Service Workers (HTTPS requirement; proxy-like behavior) — `https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers` ([MDN Web Docs][10])
- Secure contexts (powerful APIs restricted to HTTPS) — `https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Secure_Contexts` ([MDN Web Docs][18])
- Link `rel` values (noopener/noreferrer) — `https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel` ([MDN Web Docs][17])

Build tooling / env exposure references:

- Create React App env variables warning — `https://create-react-app.dev/docs/adding-custom-environment-variables/` ([create-react-app.dev][1])
- Vite env variables security notes — `https://vite.dev/guide/env-and-mode` ([vitejs][11])

Auth/token storage guidance:

- OAuth 2.0 for Browser-Based Apps (token storage discussion) — `https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps` ([IETF Datatracker][16])

Dependency tooling references:

- npm audit docs — `https://docs.npmjs.com/cli/v10/commands/npm-audit/` ([npm Docs][20])
- npm ci docs — `https://docs.npmjs.com/cli/v10/commands/npm-ci/` ([npm Docs][21])

Sanitizer reference:

- DOMPurify — `https://github.com/cure53/DOMPurify` ([GitHub][13])

[1]: https://create-react-app.dev/docs/adding-custom-environment-variables/ 'Adding Custom Environment Variables | Create React App'
[2]: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html 'Content Security Policy - OWASP Cheat Sheet Series'
[3]: https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API 'Trusted Types API - Web APIs | MDN'
[4]: https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html 'HTML5 Security - OWASP Cheat Sheet Series'
[5]: https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html 'Third Party Javascript Management - OWASP Cheat Sheet Series'
[6]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html 'Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series'
[7]: https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Subresource_Integrity 'Subresource Integrity - Security | MDN'
[8]: https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Clickjacking 'Clickjacking - Security | MDN'
[9]: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html 'Cross Site Scripting Prevention - OWASP Cheat Sheet Series'
[10]: https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers 'Using Service Workers - Web A

…(truncated)