Use Vibe Coding Security as a Pre-Launch Gate

The old article pointed at the right danger but used the wrong frame. Vibe Coding Security is not a real-time guardrail system and it is not a scanner. The repo is a static pre-launch gate: 47 checklist items, five free markdown skills, and case studies that tell an agent where to look before a vibe-coded app goes public.

That is useful for Claude Code and Codex practitioners because the work is inspectable. A serious version of the article should teach how to run the checks, which outputs deserve a stop, and why the repo cannot replace monitoring or a security review.

Why this seed is worth saving

The source repo has the material the first article failed to use. The README names six surfaces: auth, secrets, APIs, database, frontend, and deployment. It also says the five free skills live under 5-free-skills/, can be copied into .claude/skills/, and run with /skill <name> in Claude Code.

That makes the piece worth rescuing. It is not a scare story about AI-generated code. It is a workflow article about turning security review from 'ask the model if this is safe' into a set of file, SQL, and bundle checks a reviewer can reproduce.

Start with RLS, not the breach story

The strongest first check is 5-free-skills/audit-supabase-rls.md. It tells the agent to query pg_tables for rowsecurity = false, inspect pg_policies, look for anon policies, find null qual filters, and grep migrations for tables without ENABLE ROW LEVEL SECURITY.

SELECT tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
AND rowsecurity = false;

This is the right shape for a Codex task because the finding is falsifiable. Either a table returns from the query or it does not. The adoption boundary is just as important: the agent should not invent a policy and ship it alone. It should paste the failing table names into a PR, propose narrow auth.uid() policies, and make a human validate the data model.

Treat NEXT_PUBLIC_ as a build artifact

5-free-skills/find-exposed-env-vars.md is the second useful piece. It searches build output and source for leaked keys:

grep -rE "(NEXT_PUBLIC_|VITE_).*=(sk-|pk-|AKIA|ghp_|hf_|sb-|supabase)" .next/static/ dist/ build/
git log --all --full-history -p -- ".env*" | grep -E "^(\+|-).*(sk_|pk_|AKIA|ghp_)" | head -20

This is not just style guidance. Next.js documentation says NEXT_PUBLIC_ variables are inlined at build time into browser JavaScript. That means a Codex review should inspect the bundle and git history, not only the current .env.local. The reader decision is simple: if a service key appears in .next/static/, stop the launch, rotate the key, and rebuild before reviewing anything else.

Make AI-specific checks explicit

The repo becomes more than a web-app checklist when it adds 5-free-skills/audit-prompt-injection-vectors.md. That skill searches for request body, query, params, file content, or web content flowing into prompt, messages, system, or context fields.

grep -r "prompt\s*=\|messages\s*=\|system\s*=\|context\s*=" src/ --include="*.ts" --include="*.js" \
 | grep -E "(req\.|body\.|query\.|params\.|input\.)" | head -20

OWASP's prompt-injection guidance describes the same class of problem: attacker-controlled input can manipulate model behavior if the application fails to separate data from instructions. In an agent workflow, that means the review should not end at 'sanitize inputs.' The reviewer should identify where untrusted text reaches the model, which tool calls can follow, and what permissions the resulting output can exercise.

Run the free skills as a launch queue

A practical order is not the README order. Run audit-supabase-rls first if the app stores user data. Run find-exposed-env-vars before sharing any preview URL. Run audit-prompt-injection-vectors before enabling file upload, web fetch, RAG, or MCP tools. Then run audit-rate-limiting against /api/login, /api/register, and /api/forgot-password, and run find-xss-react if any user or LLM output is rendered as HTML.

The source files provide concrete anchors: grep -rE "rateLimit|RateLimit|Ratelimit|throttle|limiter" --include="*.ts", grep -rE "dangerouslySetInnerHTML" --include="*.tsx", DOMPurify, Ratelimit, and HTTP 429. Those are good agent tasks because the output can be copied into a PR checklist. They are bad autonomous fix tasks unless the maintainer agrees on the intended auth, rendering, and API behavior.

What this gate cannot prove

The README's own boundary is the most important sentence: this is not a SaaS scanner and not continuous monitoring. It is static markdown. Nothing phones home, nothing watches production, and nothing knows whether the team's business rules are correct.

That boundary prevents overclaiming. Vibe Coding Security is useful before launch, before a demo gets traffic, or before a Codex-built feature touches real accounts. It is not enough for health data, payment flows, enterprise access control, or any product where a missed policy becomes a reportable incident. In those cases, the checklist should feed a wider review rather than replace one.

A Codex adoption path

Use it as a branch gate. Copy the relevant files into .claude/skills/ for Claude Code, or keep them in a reviewed security/ folder and ask Codex to run each command on a staging branch. The key is to preserve the command output: failing pg_tables rows, .next/static/ matches, prompt-concatenation paths, missing Ratelimit code, or unsanitized dangerouslySetInnerHTML instances.

The final review should be boring. Every finding becomes one of four labels: fix now, accepted risk, false positive with source path, or requires a human security review. If an agent jumps from grep -r "service_role" src/ to sweeping rewrites, stop it. The repo is valuable because it narrows the review surface, not because it grants permission to batch-edit security-sensitive code.

Save Vibe Coding Security as a pre-launch gate for AI-built apps. It is useful when the reader runs the five free skills as reproducible checks; it is unsafe when treated as continuous monitoring, a proof of security, or an excuse to let an agent patch auth and data access without review.

Practical takeaway

Before publishing an AI-built app, copy the five files from 5-free-skills/, run the RLS, env, prompt-injection, rate-limit, and XSS checks on a staging branch, paste every failing command into the PR, and require a human decision before any auth, RLS, or secret-handling diff is merged.