frontend-security

• SKILL.mdcore · 7,513 bytes
• SKILL.mdcore · 7,513 bytes
• SKILL.mdcore · 7,513 bytes
• metadata.jsonasset · 1,545 bytes
• references/browser-controls.mddoc · 6,071 bytes
• references/verifying-findings.mddoc · 3,363 bytes

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/frontend-security/SKILL.md. -->

# Frontend Security

Browser-side hardening: XSS and safe text binding, per-sink URL policy, DOM clobbering, nonce-based CSP, Trusted Types, subresource integrity, iframe capability minimization, postMessage validation, and where client state may live. Use when generating HTML, JSX, Vue, or Svelte templates, setting response headers in a web app, embedding third-party scripts or frames, or storing anything client-side.

## ALWAYS

- Render untrusted data through the framework's ordinary text interpolation, which escapes for the output context. Do not reach for a raw-HTML API merely to display user data. Where rich HTML genuinely must be rendered, put it through a maintained sanitizer (DOMPurify) with an explicit allowlist first.
- Validate URL-bearing attributes **per sink**, not against one global scheme list. A navigation target (`href`, `action`, `formaction`, an `<iframe src>`) and an image source do not share a trust model: `javascript:` is never acceptable anywhere, while a narrowly constrained `data:image/…` or `blob:` may be exactly what an image sink requires. Decide the permitted schemes for each sink and check against that list.
- Read security-sensitive configuration and control-flow values from lexical variables or an object you own — never from a named `window` / `document` property (`window.config`, `document.redirectTo`, an implicit global). The browser exposes elements by `id` and `name` as named properties, so injected markup can shadow the value your code expected. An explicit `getElementById()` lookup is not the problem; trusting an ambient global is. Type-check what you read before using it in a privileged way.
- Build the `Content-Security-Policy` around a **nonce or hash as the trust root**: `script-src 'nonce-{value}' 'strict-dynamic'; object-src 'none'; base-uri 'none'`. Keeping `'self'` beside the nonce means every same-origin script is still trusted — that is a host-allowlist policy wearing a nonce, which may be the right trade-off but is not a strict CSP, so do not call it one. Generate the nonce from a CSPRNG afresh for **every HTML response**, and apply it only to scripts the server itself authorizes.
- Where you deploy Trusted Types, enforce `require-trusted-types-for 'script'` **and** restrict which policies may exist with the `trusted-types` directive. The first makes DOM sinks demand a typed value; without the second, any code can mint a pass-through policy (`createHTML: s => s`) and the guarantee is gone. Keep policies few, named, and centrally reviewed.