astro-securitylisted

# Astro Security ## When to use This skill is the Astro-specific layer on top of `secure-coding`. Astro mixes static-site generation, server-side rendering, and partial hydration in one codebase, which means the attack surface differs per page even within the same project. That mixed-mode reality is the single most underappreciated source of Astro security mistakes. Triggers on: - A question like "review our Astro app for security issues", "is this page SSG or SSR", "set:html on user input", "Astro API route auth", "Decap CMS hardening", "OAuth backend for Decap", "Astro middleware bypass". - Presence of `astro.config.mjs`/`.ts`, `src/pages/`, `src/middleware.ts`, `src/content/` directories, `@astrojs/*` adapters, or `decap-cms`/`netlify-cms` admin-UI files. - A PR touching `set:html`, `Astro.locals`, middleware, content-collection schemas, MDX components, or adapter config. - Astro version bumps, especially around security advisories (check the `astro` GitHub security tab). - A handoff from `security-review` or `api-security` when Astro is in the stack. ### When NOT (handoff) - General TS/JS secure-coding (not Astro-specific) → `secure-coding`. - OWASP API Top 10 as a conceptual framework → `api-security`. Here for the Astro-specific implementation of API routes. - SAST tooling (eslint-plugin-security, Semgrep `p/javascript`) → `sast-orchestrator`. - Dep vulns in `package.json` → `cve-triage`. - Adapter-platform infrastructure (Cloudflare Workers KV access, Vercel proj