frontend-render-security

frontend-render-security

AI optimizes for the shortest code that produces the requested visible behavior and omits the invisible defensive layer — the sanitizer, the origin check, the server-side gate, the security header. Large samples put XSS in a majority of AI frontend code and ~2.74× more XSS than human code; every agent in the Tenzai benchmark shipped client-side flaws. These are high-precision, grep-catchable patterns — stop them at authoring time.

When to use

• Writing or modifying a component, template, or client-side script that renders data, calls an API, handles auth, or reads the URL / postMessage.
• Reviewing an AI-authored frontend diff.
• Editing .tsx / .jsx / .vue / .svelte / .html or client-side .js / .ts.

Do NOT use when: the change is server-only, CLI, or non-UI — route to security / security-sensitive-stop.

The Iron Law

NEVER RENDER NON-CONSTANT INPUT INTO AN HTML/JS SINK WITHOUT ENCODING OR SANITIZING.
THE CLIENT IS UNTRUSTED — EVERY CLIENT GATE NEEDS A SERVER-SIDE TWIN.
NO SECRET, PRIVILEGED KEY, OR SESSION TOKEN LIVES IN CLIENT CODE OR localStorage.

Procedure

1. Identify the sinks in the diff: HTML/JS render points, API calls, auth/role checks, URL / postMessage reads, secret/token usage.
2. Run the backstop greps below; for each hit, apply the matching fix from the patterns table.
3. For every client-side gate, confirm a server-side twin exists (the client is never the security boundary).
4. Emit the per-diff verdict (Output format); surface any unresolved hit to the user.

The patterns AI ships by default

Backstop greps

Run before committing frontend changes; each should return zero (or every hit is read and justified):

# Insecure render + eval sinks
rg -n 'dangerouslySetInnerHTML|v-html|\.innerHTML\s*=|document\.write\(|\beval\(|new Function\('
# Client secrets / token storage
rg -n 'NEXT_PUBLIC_.*(SECRET|KEY|TOKEN|PASSWORD)|VITE_.*(SECRET|KEY)|localStorage\.setItem\([^)]*[Tt]oken'
# Wildcard CORS + unchecked postMessage + open redirect
rg -n "origin:\s*['\"]\*['\"]|Access-Control-Allow-Origin.*\*"
rg -n "addEventListener\(\s*['\"]message['\"]"   # then confirm each checks event.origin
# Unhardened external links
rg -n 'target=["'\'']_blank["'\'']'   # then confirm rel="noopener" present

Output format

1. A per-diff verdict listing each pattern class checked and its result (clean / hit at file:line → fixed by <change>).
2. The backstop greps run, with results.
3. For any client gate added, the file:line of its server-side twin (or an explicit note that the server check already exists and where).

Gotcha

• Modern browsers default _blank to noopener, but legacy/embedded webviews do not — keep the rel for portability.
• NEXT_PUBLIC_/VITE_ on a genuinely public value (a publishable analytics ID) is fine; the violation is a sensitive name behind that prefix. Read the name, don't blanket-block the prefix.
• A sanitizer (DOMPurify) is the fix only when HTML output is actually required; if plain text suffices, render text and skip the dependency.
• Client-side validation is not wrong — it is wrong as the only enforcement. Keep it for UX; add the server twin.

Do NOT

• Do NOT render user/DB HTML through dangerouslySetInnerHTML/v-html/innerHTML without a sanitizer.
• Do NOT put a secret, privileged key, or session token in client code or web storage.
• Do NOT treat a client-side role/auth check as a security boundary.
• Do NOT set origin: '*' on a credentialed endpoint.
• Do NOT auto-strip a grep hit without reading it — some innerHTML uses are on constant, trusted markup.

Auto-trigger keywords

• frontend security
• XSS
• dangerouslySetInnerHTML
• client-side secret
• insecure render

See also

• ai-code-blindspots — the surface→controls checklist that routes here.
• senior-engineering-discipline — anchor rule.
• security, defense-in-depth, accessibility-auditor, secrets-management.