Frontend security
Skill ShieldNet-360/secure-vibe/dist/agent-skills/.agents/skills/frontend-security
SecureVibe — prevention-first security for AI-written code. Signed SKILL.md knowledge that makes AI coding assistants write secure code at generation time, plus a deterministic CI gate. Offline · keyless · Ed25519-signed. By ShieldNet360.
npx -y skills add ShieldNet-360/secure-vibe --skill frontend-securityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Browser-side hardening: XSS, CSP, CORS, SRI, DOM clobbering, iframe sandboxing, Trusted Types — Applies to: when generating HTML / JSX / Vue / Svelte templates; when wiring up response headers in a web app; when adding third-party script tags or CDN resources
SKILL.md
4.1 KB, as published. Nobody here has run it
Frontend Security
Browser-side hardening: XSS, CSP, CORS, SRI, DOM clobbering, iframe sandboxing, Trusted Types
ALWAYS
- Treat all user/URL/storage data as untrusted. Render via framework escaping (
{}in JSX/Vue/Svelte,{{ }}in templating). For raw HTML use a vetted sanitizer (DOMPurify) with a strict allowlist. - Send a strict
Content-Security-Policyheader. Minimum production baseline:default-src 'self'; script-src 'self' 'nonce-<random>'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests. Use nonces or hashes — never'unsafe-inline'forscript-src. - Set
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload,X-Content-Type-Options: nosniff,Referrer-Policy: no-referrer-when-downgradeor stricter, andPermissions-Policyto drop unused features. - Add
integrity="sha384-..." crossorigin="anonymous"to every<script>and<link rel="stylesheet">loaded from a CDN. - Add
sandbox="allow-scripts allow-same-origin"(only the attributes you need) to every<iframe>. Default to no allow flags. - Use cookies with
Secure; HttpOnly; SameSite=Lax(orStrictfor sensitive flows).__Host-prefix when there's no subdomain sharing. - Enable Trusted Types where browser support allows (
Content-Security-Policy: require-trusted-types-for 'script') so DOM-sink assignments (innerHTML,setAttribute('src', ...)for scripts) must be routed through a typed policy.
NEVER
- Use
dangerouslySetInnerHTML,v-html,{@html ...},innerHTML =, ordocument.writewith untrusted input. - Use
eval,new Function,setTimeout(string),setInterval(string), orFunction('return x'). - Inject user input into
href,src,formaction,action, or any URL-bearing attribute without scheme validation (blockjavascript:,data:,vbscript:). - Use
target="_blank"withoutrel="noopener noreferrer"— leakswindow.opener. - Trust DOM nodes by id alone. DOM clobbering: an attacker-controlled
<input name="config">shadowswindow.config. - Use
postMessagewithout checkingevent.originagainst an allowlist. - Store JWTs, refresh tokens, or PII in
localStorage/sessionStorage— any XSS exfiltrates them. Prefer HttpOnly cookies. - Read or write
document.cookiefrom JavaScript for auth cookies — they should be HttpOnly anyway. - Treat tightening the HTML sanitizer as the fix when the exploit rides on content the sanitizer allows by design — a valid
<a href="https:…">, an<img src>, or a permitted attribute. The sanitizer is working; the vulnerable behaviour is downstream (in-app navigation, a shell /openExternalsink, an over-privileged renderer or IPC bridge, a URL sink). Fix the sink / context, not the markup allowlist.
KNOWN FALSE POSITIVES
- Internal admin tools deliberately rendering Markdown / rich text from trusted authors may use
dangerouslySetInnerHTMLafter a sanitizer pass; document the sanitizer call inline. - Browser extensions sometimes need
'unsafe-eval'in the extension CSP; user-facing web app CSP should still forbid it. - WebSocket connections to non-same-origin endpoints are fine when the server performs origin validation.
- A native / WASM codec, decoder, or loader that is merely registered or referenced (
setDRACOLoader(...), a plugin registration, a lazy import) is not an active attack surface unless its binary / asset is actually shipped and the module initialized at runtime. Verify asset-present + module-init + reachable input format before flagging — wiring alone is a false positive (inputs needing the missing decoder simply fail to load).