A vibe code security audit, ordered by time budget instead of category.

Because most vibe-coded apps get audited under deadline pressure, not at the start of a quarter. The classic shape (front-end, back-end, dev-ops, monitoring) reads well in a blog post but gives you no priority signal when you have one evening before launch. A triage order says: the first 60 minutes go to the things that, if wrong, mean the app is already compromised the moment a stranger clicks Sign Up. The next 4 hours go to the trust boundaries between users and between vendors. The remaining day goes to hardening that matters but is not on fire. If you only ever do pass 1, you have closed the catastrophic class of bugs. The category-shaped lists do not give you that, because category-shaped lists treat verbose error messages and an exposed Stripe key as peers.

Run git log and grep the working tree for keys (SUPABASE_SERVICE_ROLE_KEY, OPENAI_API_KEY, STRIPE_SECRET_KEY, AWS keys, any token shape ending in a long base64 string). Then pull the .env from the deploy host and confirm none of those are in the public repo. Second, hit every API route that mutates data without an auth header; if even one returns 200, you have an unauthenticated write endpoint. Third, log in as user A, copy the URL of any record they own, log in as user B in a different browser, and try to load it; if it returns user A's data, you have IDOR. Fourth, look at the sign-up form and confirm there is a real password hash function on the server, not a homemade SHA256 or, worse, a plaintext compare. Those four checks usually take under an hour and they cover the failure modes that cause an instant front-page incident.

First, CSRF on every state-changing route that uses cookie auth. Second, per-IP rate limit on /api/login, on any password-reset endpoint, on /api/signup, and on any endpoint that costs you money to serve (an LLM call, a transactional email send). Third, row-level security if you are on Postgres or Supabase, with a written test that proves user A cannot select from user B's rows even with a forged JWT. Fourth, the line every other checklist still misses: an OAuth scope audit on every AI vendor or third-party tool connected to your data. The April 2026 Vercel breach started with one Context.ai employee's compromised Google account and an 'Allow All' OAuth scope; that scope let attackers pivot into Vercel's Google Workspace and environment variables, and ShinyHunters listed the data for $2M. Treat every Allow All scope on every AI integration as a credential you handed to the next breach.

CORS configured to a specific allowlist instead of wildcard. Content-Security-Policy header with at least default-src self and a script-src that does not include unsafe-inline (or, if it does, a written reason). HSTS, X-Content-Type-Options, Referrer-Policy. A dependency audit that flags any unverified package the AI assistant suggested but you did not personally choose (slopsquatting check: many AI agents hallucinate package names that match no real npm or PyPI entry, then a malicious actor publishes one to that name). File-upload validation that does not trust the client-provided MIME type. Error responses that do not leak stack traces or table names. Stripe webhooks with signature verification and idempotency keys. None of these is going to put you on the front page tomorrow, but each one is the cheap layer of defense that stops the second-day attacker who already got past the obvious holes.

Because most of the public checklists predate the April 2026 wave of breaches that came through AI integrations. The dominant lists I cross-checked (the benavlabs vibe-check repo with 17 categories, the Replit security tutorial, the Aikido four-tier guide, the Cloud Security Alliance Secure Vibe Coding Guide) all enumerate the OWASP-style classics: RLS, secrets in source, CSRF, rate limit, headers, parameterized queries, file uploads. None of them lists 'audit the OAuth scopes you granted to every AI vendor that touches your data' as a checklist line. After the Vercel and Context.ai pivot, that line is the most underweighted item on the entire surface. It belongs on every audit.

Service SVC-007 on the homepage is a fixed-fee AI Vendor Security Review. It was added to the services list in direct response to the April 2026 Vercel and Context.ai breach. The deliverable is a written audit of every AI tool in the stack, the OAuth scopes each one was granted, env-var hygiene across deploy hosts, and a remediation list ordered by blast radius. The work fits the published $500 to $2,000 small-integration tier on this site, lands in a few days, and pairs with the AI Stack Selection audit (SVC-008) for teams that also want a second opinion on which platforms and models to keep. Rates are on the page, not behind a strategy call.

Run both. A SAST tool (Semgrep, GitHub CodeQL, the open-source Aikido tier) catches the syntactic patterns at scale: weak crypto calls, hardcoded secrets, dangerous sinks. A dependency scanner catches known-CVE packages. A vibe-coded app benefits a lot from a one-time scan because the AI assistant tends to ship the same handful of antipatterns over and over. What automation will not catch is the architectural mistakes: an authorization model that lets user A read user B's records by ID, an OAuth scope that grants Allow All to a vendor you no longer use, a webhook handler with no idempotency. The hand pass and the automated scan are not substitutes; they cover different layers, and the manual triage is what catches the breach-grade mistakes.

It can do parts of it, and it cannot do other parts. It is genuinely useful for the static checks: running grep across the working tree for known secret shapes, walking every API route and listing the ones with no auth middleware, listing every external package and flagging the ones that resolve to obscure or unverified registries. It is bad at the architectural checks because it does not have your customer data, your billing geography, or your real traffic shape, and it tends to vouch for code it wrote earlier in the session. The right division of labor: agent generates the inventory and the static report, human reads the inventory and runs the cross-user IDOR test, the OAuth scope walk, and the rate-limit threshold conversation. That same split shows up in every consulting engagement on this site.

On c0nsl the work fits the published $500 to $2,000 small-integration band for an SMB-sized app (one auth surface, one data store, a handful of integrations) and lands in a few days. If the stack also includes a Cloudflare Worker layer, multi-zone alignment, a Fastly or AWS WAF component, or a SOC-style alerting pipeline, the engagement moves into the $2,000 to $10,000+ custom-system tier. Either way, the rate and the deliverable are on the page; there is no rate-card mystery and no follow-up sales call before you see a number. The first conversation is the published $75 consult, and the only reason to start there is to confirm whether your stack actually fits the kind of audit this checklist describes.

Run pass 1 yourself in 60 minutes tonight. If any of the four checks come back red (committed key, unauthenticated write, IDOR, plaintext password), pause the launch and fix those before you do anything else. If pass 1 comes back clean, run pass 2 over the weekend; the four trust-boundary items (CSRF, rate limit, RLS, AI-vendor OAuth scopes) are the next class of bug that hits real users. If you finish pass 2 clean, you are in the cohort that can launch with a straight face. Pass 3 can run in the week after launch without putting you in danger. If you find something in pass 1 or pass 2 that you do not understand the fix for, the published $75 consult on the homepage is the cheapest way to get a second pair of eyes on it.