agentsclimarketplace

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.

Install
npx -y skills add ShieldNet-360/secure-vibe --skill frontend-security

Assembled 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

<!-- 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, 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-Policy header. 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' for script-src.
  • Set Strict-Transport-Security: max-age=63072000; includeSubDomains; preload, X-Content-Type-Options: nosniff, Referrer-Policy: no-referrer-when-downgrade or stricter, and Permissions-Policy to 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 (or Strict for 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 =, or document.write with untrusted input.
  • Use eval, new Function, setTimeout(string), setInterval(string), or Function('return x').
  • Inject user input into href, src, formaction, action, or any URL-bearing attribute without scheme validation (block javascript:, data:, vbscript:).
  • Use target="_blank" without rel="noopener noreferrer" — leaks window.opener.
  • Trust DOM nodes by id alone. DOM clobbering: an attacker-controlled <input name="config"> shadows window.config.
  • Use postMessage without checking event.origin against an allowlist.
  • Store JWTs, refresh tokens, or PII in localStorage / sessionStorage — any XSS exfiltrates them. Prefer HttpOnly cookies.
  • Read or write document.cookie from 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 / openExternal sink, 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 dangerouslySetInnerHTML after 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).

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.