Run your vibecoded app through the detector before someone else does
An application shipped over three evenings works. That does not make it safe. This run-through revisits where a generated app bleeds first, in the order that matters: what already got out, what gives way effortlessly, what waits for an attacker, what rots on its own.
Why
The first instinct is nearly always the wrong one. When you find an API key in browser-side code, you remove it and commit again. The secret still sits readable in the repository history, in every clone made since, and with anyone who opened the page. Deleting the line treats the symptom and leaves the door open. That is what this run-through is for: it imposes the order. First revoke what has already left, then try for yourself the attacks that need no tooling, and only afterwards touch the sophisticated code. A vibecoded application rarely falls to clever injection. It falls to an admin…
When
Before showing the product to someone who matters. When handing a link to a client, putting the application in front of real accounts, or taking the first payment. Also when you inherit an application you did not write and nobody knows what it exposes. This is not a monitoring routine: it is a mandatory pass before a public launch, then once a quarter.
Tools included
- Claude Code
- Security Reviewer
- Github
- Supabase
- Zod
- Sentry