web-security-review

Web and Electron Security Review (JavaScript / TypeScript)

Leaf-mode guard

If the task identifies your role as leaf-reviewer or sets delegation-budget: 0, read and follow references/validation-pass.md, validate only the supplied candidates, return the verdicts to the caller, and stop before the full workflow below.

Identify exploitable security vulnerabilities in JavaScript/TypeScript web and Electron desktop applications. Reason about the code the way a security researcher would — trace data flow, understand framework and runtime protections, and report only findings you can justify with concrete proof. Signal over noise.

This skill is a best-of-three composite. See ATTRIBUTION.md.

Scope

In scope: Node.js/TypeScript backends (Express, NestJS, Fastify, Next.js API routes), browser/SSR frontends (React, Vue, Angular, Next.js), and Electron main, preload, renderer, worker, and utility-process code. Server-side, client-side, and desktop JS/TS, plus the config, packaging, CI/CD, and IaC files that ship with them.

Out of scope: other languages (defer to a language-specific reviewer) and the exclusions in references/false-positives.md.

Report vs. research — the prime directive

• Report on: only the file, diff, or path the user asked about.
• Research: the entire codebase to establish the facts before reporting.

Before flagging anything, trace where the input actually comes from, whether it is validated/sanitized upstream, how it is configured, and what framework protection applies. Never report on pattern-match alone. Investigate first, report second.

Reporting gate: proof, not probability

Report a finding only when you can construct concrete proof appropriate to the class. If you can't describe how the bug actually manifests, it isn't a finding. Use one of these proof shapes:

• Data-flow flaw: the exact attacker-controlled input, its route through the code, and the security-sensitive sink it reaches.
• Exposure flaw: the sensitive value or resource, where an attacker can observe or retrieve it, and why the value is real and security-relevant. Never validate a suspected credential against a live service.
• Configuration flaw: the effective unsafe setting, the attacker capability or reachable operation it affects, the security boundary it removes, and the concrete resulting impact.