Five rule files mirroring per-language convention (coding-style, hooks, patterns, security, testing). Each has `paths:` glob frontmatter for auto-activation when editing matching files. - coding-style.md: file extensions, naming, JSX, RSC boundary - hooks.md: React hooks (NOT Claude Code hooks) — rules-of-hooks, dep arrays, cleanup, memoization, React 19 additions - patterns.md: container/presentational split, state location decision tree, Suspense + error boundaries, forms, data fetching - security.md: dangerouslySetInnerHTML, unsafe URL schemes, server-action validation, env-var leaks, CSP - testing.md: RTL queries, userEvent, async, MSW, axe, anti-patterns Each file extends typescript/* and common/* rules.
6.1 KiB
paths
| paths | |||||
|---|---|---|---|---|---|
|
React Security
This file extends typescript/security.md and common/security.md with React specific content.
XSS via dangerouslySetInnerHTML
CRITICAL. The prop name is deliberately scary — treat every usage as a code review halt.
// CRITICAL: unsanitized user input
<div dangerouslySetInnerHTML={{ __html: userBio }} />
// CORRECT options:
// 1. Render as text
<div>{userBio}</div>
// 2. Render parsed markdown via a library that sanitizes
<ReactMarkdown>{userBio}</ReactMarkdown>
// 3. If raw HTML is required, sanitize first with DOMPurify
import DOMPurify from "isomorphic-dompurify";
<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userBio) }} />
Audit checklist for every dangerouslySetInnerHTML call:
- Is the input always under our control? Document the source.
- If user-derived: is it sanitized at the same call site? (Sanitization at the API boundary is acceptable only if every consumer is verified.)
- Is the sanitizer config allowlisting tags, not denylisting?
Unsafe URL Schemes
javascript: and data: URLs in href, src, and xlink:href execute arbitrary code.
// CRITICAL: javascript: URL injection
<a href={user.website}>Visit</a> // if user.website = "javascript:alert(1)"
// CORRECT: validate scheme
function safeUrl(url: string): string | undefined {
try {
const parsed = new URL(url);
if (["http:", "https:", "mailto:"].includes(parsed.protocol)) return url;
} catch {
return undefined;
}
return undefined;
}
<a href={safeUrl(user.website)}>Visit</a>
React 18+ blocks javascript: URLs in href and logs a warning, but data: URLs and other schemes still slip through. Always validate.
target="_blank" Without rel
<a target="_blank"> without rel="noopener noreferrer" lets the target page access window.opener and run navigation hijacks.
// WRONG
<a href={externalUrl} target="_blank">External</a>
// CORRECT
<a href={externalUrl} target="_blank" rel="noopener noreferrer">External</a>
Modern browsers default to noopener when target="_blank", but do not rely on browser defaults — be explicit.
Server Action Input Validation
Server Actions ("use server") run with the same trust level as a public API endpoint. Validate every input.
"use server";
import { z } from "zod";
const Input = z.object({
email: z.string().email(),
age: z.number().int().min(0).max(120),
});
export async function updateUser(_state: unknown, formData: FormData) {
const parsed = Input.safeParse({
email: formData.get("email"),
age: Number(formData.get("age")),
});
if (!parsed.success) return { error: parsed.error.flatten() };
// ...
}
- Authenticate inside the action — do not trust the client-side route gate
- Authorize: confirm the current user has permission for the specific record they are mutating
- Rate limit sensitive actions
Secret Exposure via Env Vars
Prefixed env vars are bundled into the client. Treat them as public.
| Framework | Public prefix | Private |
|---|---|---|
| Next.js | NEXT_PUBLIC_* |
All others |
| Vite | VITE_* |
.env server-side only |
| Create React App | REACT_APP_* |
None — CRA exposes all |
| Remix | process.env access in loader/action only |
Same |
// CRITICAL: secret leaked to client bundle
const apiKey = process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY;
Audit on every PR that touches env vars: would this string in the public bundle be a problem?
Authentication / Authorization
- Never store sessions in
localStorage— accessible to any XSS. Use httpOnly secure cookies. - Never trust client-set state to gate sensitive UI. Render-gating in JSX prevents display, not access — the API must enforce.
- CSRF: cookie-based auth requires CSRF tokens or
SameSite=Strict/Laxcookies - Use double-submit cookies or origin verification for form actions when not using framework defaults
Content Security Policy (CSP)
Configure server-side. The minimum acceptable CSP for a React app:
default-src 'self';
script-src 'self' 'nonce-{REQUEST_NONCE}';
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
connect-src 'self' https://api.example.com;
frame-ancestors 'none';
- Avoid
unsafe-inlineandunsafe-evalinscript-src - For SSR with inline scripts (Next.js streaming, hydration data), use per-request nonces — both Next.js and Remix support nonce injection
style-src 'unsafe-inline'is often unavoidable for CSS-in-JS libraries — document the tradeoff
Prototype Pollution via Object Spread
// WRONG: untrusted JSON spread directly into state
const update = await req.json();
setState({ ...state, ...update }); // attacker controls __proto__
// CORRECT: parse with a schema, or guard keys
const Allowed = z.object({ name: z.string(), email: z.string().email() });
const parsed = Allowed.parse(await req.json());
setState({ ...state, ...parsed });
SSR Template Injection
When using renderToString or renderToPipeableStream:
- All values rendered inside JSX are escaped by React — safe
- Values passed to
dangerouslySetInnerHTMLare NOT escaped — same rules as client - Manually constructed HTML wrappers around the React output must be escaped or sanitized — never concatenate user input into the surrounding HTML template
Third-Party Components
- Audit
npm auditbefore adding any UI library - Check that the library does not internally use
dangerouslySetInnerHTMLon its input (e.g., rich text editors) - Pin versions, review changelogs before major upgrades
- Be wary of components that accept HTML strings as props
Source Map Exposure in Production
Production builds should ship without source maps, or with sourcemaps uploaded to an error tracker (Sentry) and stripped from the public bundle. Public source maps leak internal logic and file structure.
Agent Support
- Use
security-revieweragent for comprehensive security audits across the codebase - Use
react-revieweragent for React-specific patterns and the above rules in active code review