security-barlisted

# security-bar ## Overview My security checklist. It layers on top of `security-review` (reference it for the broad sweep) and adds the things that actually bite me. Usable standalone on a diff, and invoked by the quality stage of `eskills:task-flow`. This is the **defensive** lens ("is this built right?"). For an **offensive** pass — hunting reachable, exploitable paths to a sink — use `eskills:exploit-hunt`; it's the counterpart, not a per-task default. ## The principle I keep relearning **Client-side guards are not security.** The anon key ships in the client; a PIN, a rate-limit, or a check that lives only in front-end code provides zero server-side protection. If it must be enforced, it is enforced on the server. ## Checklist - **Input handling** — validate and bound every external input (size, type, shape). Parse, don't trust. Watch unbounded growth (a field that can balloon a stored blob). - **Secrets** — none in the client bundle or the repo; only public-by-design keys are client-side. Confirm what a shipped key can actually do. In Vite the mechanism is static inlining at build time: anything `VITE_`-prefixed is pasted into the bundle, and minification is not obfuscation. Two config lines silently widen that blast radius — `loadEnv(mode, cwd, '')` (empty prefix loads **every** host variable, server secrets included) and `envPrefix: ''`. Keep production `build.sourcemap` off unless the maps go to an error tracker; otherwise you ship your original s