frontend-securitylisted

<!-- Native skill bundle for Claude Code. 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 (`wi