← ClaudeAtlas

security-barlisted

Use when reviewing changes for security to apply my checklist on top of security-review — input handling, secrets, authz, Supabase RLS, egress limits, server-side PIN enforcement, and the agent-harness surface (config secrets, hook injection, MCP risk, over-broad permissions).
Endika/eskills · ★ 0 · AI & Automation · score 72
Install: claude install-skill Endika/eskills
# 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. - **Authz** — every privileged action checks who's allowed, server-side. No "the UI hides the button" as the only control. - **Supabase RLS** — no table with open anon `SELECT true` **and** `INSERT/UPDATE true`; that lets anyone with the anon key read and overwrite rows via PostgREST, bypassing the app. Restrict direct writes; route privileged writes through an RPC that checks the rule. - **Server-side PIN / ownership enforcem