security-web

name

security-web

description

Web application security review for TypeScript/JavaScript stacks, frontend and backend: XSS and output encoding, CSRF, clickjacking, secrets leaking into client bundles, authn/authz and IDOR, injection (SQL/command/NoSQL/ template), SSRF, mass assignment, insecure deserialization, file upload, path traversal, security headers and cookie flags, and dependency/supply- chain risk. Includes targeted rules for Next.js (Server Actions, route handlers, middleware, `NEXT_PUBLIC_`, RSC data exposure), Nuxt (Nitro server routes, `runtimeConfig` vs `public`, `v-html`), Bun (`Bun.serve`, `Bun.$` shell, file serving), and Hono (middleware order, JWT, CORS, context). Use when reviewing or writing web code for vulnerabilities, triaging a security finding, or answering "is this exploitable / how do I fix it" questions. Ships secure-default config templates and a finding report format.

Web Application Security Review

Treat every byte that crossed a network boundary as hostile until proven otherwise, and prove it on the server. The client is an untrusted rendering surface you do not control. Frameworks add convenience (Server Actions, Nitro routes, Bun.serve, Hono middleware) that hides the trust boundary — this skill's job is to make the reviewer see the boundary the framework obscured.

🎯 Why: Design for Change

The goal of writing software is to be able to change it safely. Secure-by-default config (CSP, cookie flags, parameterized queries, authz-at-the-edge) means the next feature ships without re-litigating the threat model. Every insecure default you accept becomes a foothold the next change has to step around.

This skill is for security review and secure implementation. For general TypeScript correctness use typescript-best-practices; for schema-level integrity use postgres-dba. This skill never assumes another layer will catch it.

How to use this skill (review workflow)

1. Map the attack surface first. Identify every trust boundary: HTTP handlers, Server Actions, form posts, websocket frames, file uploads, outbound fetches, postMessage, process.env reaching the client, third-party script tags. A vuln you didn't enumerate is a vuln you didn't find.
2. Triage each input against the decision guide below; open the matching references/*.md for the exploit, the vulnerable pattern, the fix, and the false-positive caveat.
3. Apply the framework reference (references/nextjs.md, nuxt.md, bun.md, hono.md) — the generic finding almost always has a framework-specific trap or a framework-specific fix.
4. Report findings in the standard format (templates/finding.md): severity, location (file:line), a concrete exploit walkthrough, and the minimal fix. No exploit path stated → it is an observation, not a finding; say which.
5. Recommend the secure default, not a bespoke patch. The templates/ configs (CSP, security headers, cookies, CORS) are the target state; a one-off escape is a stopgap.

Severity (how to rank a finding)

Severity	Bar
Critical	Unauthenticated RCE, auth bypass, secret/PII mass disclosure, SQLi on a reachable path
High	Stored XSS, IDOR on sensitive data, SSRF to internal network, privilege escalation, CSRF on a state-changing action
Medium	Reflected XSS needing interaction, missing security headers with a real impact, weak session handling, verbose error leakage
Low	Defense-in-depth gaps with no direct exploit, missing hardening, informational

Rank by exploitability and blast radius on this codebase, not by the generic CVSS of the bug class. State the assumption that makes it that severity.

The hard rules (non-negotiable defaults)

1. All trust decisions happen server-side, per request, per object. Authentication establishes who; authorization re-checks may this principal touch this specific resource on every access. A hidden button, a disabled field, or a client-side route guard is UX, never a control. Object-level checks are mandatory — assume every ID in a request was tampered (IDOR). See references/backend.md.

2. Untrusted data is validated at the boundary and encoded at the sink. Parse external input with a schema (zod/valibot) into a typed value; never cast. Encode for the exact context at output — HTML, attribute, JS, URL, SQL, shell, OS path are different escapings. innerHTML, dangerouslySetInnerHTML, v-html with anything request-derived is a finding until a vetted sanitizer (DOMPurify, server-side) is proven in the path. See references/frontend.md, references/backend.md.

3. Secrets never cross to the client. No secret in a NEXT_PUBLIC_* / NUXT_PUBLIC_* / VITE_* / PUBLIC_* var, in an RSC payload, in a serialized loader/useState, in client JS, or in the repo. The client bundle is public. Treat any secret that ever shipped as compromised: the fix is rotation, not deletion. See references/frontend.md.

4. Injection is closed by structure, not by filtering. Parameterized queries / prepared statements for SQL; argument arrays (never a shell string, never Bun.$ interpolating input) for processes; no user-controlled keys into eval/Function/template compilation/object prototypes. Denylists and escaping-by-hand are findings. See references/backend.md.

5. Outbound requests to user-influenced URLs are denied by default. SSRF: allowlist host + scheme, resolve and reject private/link-local/ metadata IPs, and disable or re-validate redirects. "We fetch the URL the user gave us" is High until proven constrained. See references/backend.md.

6. Cookies and headers carry their security flags or it's a finding. Session cookies: HttpOnly, Secure, SameSite (Lax min; None requires a stated cross-site reason), host-scoped, sane Max-Age. Responses: CSP (no unsafe-inline/unsafe-eval without justification), X-Content-Type-Options: nosniff, frame-ancestors/X-Frame-Options, HSTS on HTTPS. See templates/security-headers.md.

7. State-changing requests are CSRF-protected. Cookie-authenticated POST/PUT/DELETE (incl. Next.js Server Actions and Nuxt/Nitro POST routes) need SameSite and either a synchronizer/double-submit token or a verified Origin/Sec-Fetch-Site check. Token-in-header APIs are exempt only if they never accept the credential from a cookie.

8. Framework "magic" endpoints are public endpoints. A Server Action, a Nitro defineEventHandler, a Bun.serve fetch, a Hono route is an internet-facing handler: it gets explicit authn, authz, input validation, and rate limiting regardless of how the framework lets you call it from your own UI. The caller is the attacker, not your form.

9. Fail closed and quiet. On auth/validation failure: deny, log server-side with context, return a generic error. No stack traces, no SQL, no internal hostnames, no "user not found vs wrong password" oracles in responses.

Decision guide

Symptom / what you're reviewing	Where
Request data rendered into the DOM / JSX / template	references/frontend.md §XSS
dangerouslySetInnerHTML, v-html, innerHTML, document.write	references/frontend.md §XSS, framework refs
eval, new Function, setTimeout(string), template-string compiled	references/frontend.md §XSS, backend.md §injection
postMessage handler without strict origin check	references/frontend.md §postMessage
Page can be framed; clickjacking on a sensitive action	references/frontend.md §clickjacking
Token/key/PII visible in client bundle, network tab, or RSC payload	references/frontend.md §secrets, framework refs
target="_blank" without rel, open redirect, javascript: URL	references/frontend.md §navigation
Login/session/JWT/cookie handling	references/backend.md §auth-sessions
An ID/slug from the request used to fetch or mutate a record	references/backend.md §authz-idor
SQL/Mongo/Prisma raw query built from input	references/backend.md §injection
exec, spawn with a shell, Bun.$, child process from input	references/backend.md §injection, bun.md
Server fetches a URL/host the user supplied (webhook, image proxy)	references/backend.md §ssrf
Object.assign/spread of request body into a model; ORM create(body)	references/backend.md §mass-assignment
File upload, file download, path/filename from input	references/backend.md §files
JSON.parse/yaml/node-serialize/pickle-like on untrusted bytes	references/backend.md §deserialization
Rate limiting / brute force / enumeration / resource exhaustion	references/backend.md §abuse
CORS config, Access-Control-Allow-Origin: * with credentials	references/backend.md §cors, hono.md
Dependency risk, lockfile, postinstall, typosquat, CDN script	references/backend.md §supply-chain
Next.js: Server Action, route handler, middleware, RSC, env	references/nextjs.md
Nuxt: Nitro route, runtimeConfig, useFetch SSR, v-html	references/nuxt.md
Bun: Bun.serve, Bun.$, Bun.file, password hashing, env	references/bun.md
Hono: middleware order, jwt(), cors(), context, validator	references/hono.md

Reference files

• references/frontend.md — browser-side: XSS (all sinks/contexts), CSP as mitigation, DOM clobbering, postMessage, clickjacking, tabnabbing, open redirect, secrets in the bundle, client storage, third-party scripts.
• references/backend.md — server-side: authn/session/JWT, authz/IDOR, injection (SQL/NoSQL/command/template), SSRF, mass assignment, deserialization, file handling/path traversal, CORS, rate limiting/abuse, error handling, supply chain.
• references/nextjs.md — Server Actions as endpoints, route handler vs Server Component trust, middleware.ts limits, NEXT_PUBLIC_, RSC/ serialization leakage, next/image & rewrites as SSRF, caching auth.
• references/nuxt.md — Nitro defineEventHandler, runtimeConfig vs public, SSR data serialized into the payload, v-html, server-only utils, route rules, proxy/SSRF.
• references/bun.md — Bun.serve (no framework safety net), Bun.$ shell injection, Bun.file/static serving path traversal, Bun.password vs hand-rolled hashing, Bun.env, SQLite/sql parameterization.
• references/hono.md — middleware ordering (auth before handler), built-in jwt/csrf/cors/secureHeaders, c.req validation with the validator/zod middleware, context var trust, edge runtime caveats.

Templates (recommend these as the target state)

File	Use
templates/finding.md	The report format every finding must follow
templates/security-headers.md	CSP + headers + cookie flags per framework
templates/cors.md	Correct origin-reflection allowlist (not *)
templates/input-validation.ts	Boundary schema-parse pattern (zod)
templates/review-checklist.md	The pass to run before sign-off

What this skill will not do

• Bless input sanitization by denylist/regex as an injection or XSS fix. Structure (parameterization, contextual encoding, vetted sanitizer) only.
• Bless client-side-only authorization, validation, or "security by obscurity" (hidden routes, minified code, disabled buttons).
• Bless dangerouslySetInnerHTML/v-html/innerHTML on request-derived data without a named, server-or-DOMPurify sanitizer in the proven path.
• Bless Access-Control-Allow-Origin: * together with credentials, or reflecting Origin without an allowlist.
• Bless a custom crypto/JWT/hash/CSRF implementation where a vetted library (or Bun.password, framework csrf()) exists.
• Downgrade a finding to "won't fix" inside this skill — it reports severity and the fix; the human owns acceptance.