If you built a SaaS with an AI assistant and never read the authorization code, a vibe coding security audit is the cheapest way to find out what you missed. A public walkthrough from August 2026 shows the workflow applied to four open-source projects, with findings reported to maintainers through GitHub issues rather than private exploits.
Vibe Coding Security Audit: What the Prompt Actually Checks
A vibe coding security audit is a structured review of a codebase using an agentic coding tool and a written checklist, ending in a severity-ranked report. The prompt demonstrated in August 2026 covered weak database rules, browser permission settings, exposed keys, unvalidated input, and the Git history, then wrote findings to a PDF.
The walkthrough comes from a Brazilian channel run by mano deyvin, who published the prompt free on Substack and ran it against four open-source projects he did not write. The video is titled "EXECUTA ESSE PROMPT E ME AGRADEÇA DEPOIS" and appeared on 28 August 2026. The agentic CLI used in the demonstration was Claude Code, Anthropic terminal-based coding agent.
The prompt's design matters more than the tool. Each report opens with a methodology note listing what was searched for, then separates verified strengths from risks, then details each finding with the exact file and an explanation of why the issue is exploitable. The last section drafts the issues the maintainer should receive.
That structure solves the main failure of generic prompts, which tend to return confident warnings with no location and no reasoning. A finding you cannot trace to a file and an exploit path is not a finding yet.
The Four Open-Source Projects That Were Audited
Four Brazilian open-source SaaS projects were cloned and audited locally, and the video presents them in increasing order of architectural complexity. Each project sits at a different stage of maturity, which is part of why the comparison is useful.
- Curió: a notes, tasks and reminders app built in Flutter for Android and Windows, described by its author as roughly 99% vibe coded, with data stored locally and no login required.
- An investment management app with local encryption, credited in the video to a developer whose handle the transcript renders unreliably.
- A WhatsApp login project built to let a user run their own WhatsApp integration without an external provider, dormant for around nine months at the time of recording.
- An open-source WhatsApp and Instagram business messaging platform running in production, described as multi-tenant, with several companies sharing one database.
The fourth project is the important one. A multi-tenant codebase with live customers concentrates exactly the failure modes that matter commercially: row-level rules, tenant boundaries, webhook validation, and API key storage.
Findings Ranked by Severity Across the Four Reports
The audit produced a different finding profile for each project, ranging from a single critical issue in one report to none in another. Severity counts below come from the video's description of each PDF and have not been independently reproduced.
| Project | Critical | High | Medium | Low / Info | Noteworthy finding |
|---|---|---|---|---|---|
| Curió | 1 | 0 | 3 | 1 | Local server broadcast a data snapshot to the whole local network |
| Investment app | 1 | 2 | 2 | 4 | Authorization appeared to exist but the server trusted the request body |
| WhatsApp login | several | not stated | not stated | not stated | OTP verification ran entirely in the browser |
| Multi-tenant messaging | 0 | 4 | 6 | 3 | Secrets readable across organizations; RLS by row only |
The multi-tenant platform's report is the most instructive because none of its 13 findings were critical. Its problems were permission-shaped: third-party secrets readable by any member, a generic webhook that could edit or delete messages in another organization by external ID, and API keys stored in plain text and compared by simple equality.
The investment app's report shows what a deceptive check looks like. The server read a privilege field from the request body, and an HTTP 403 on a nearby line gave the endpoint the appearance of protection without providing it.
Why Row-Level Security and Client Bundles Keep Appearing
Two failure patterns repeat across vibe-coded SaaS because the tool writes plausible code and the developer never inspects the layer where trust is decided. The first is authorization that lives in the browser or in the request body. The second is a secret compiled into the frontend bundle.
The WhatsApp login project showed both. According to the report described in the video, OTP verification happened client-side, and provider API keys plus the Meta access token were embedded in the browser bundle. A verification code generated with an ordinary random number function adds a third weakness, since counter-style guessing with no rate limit defeats short codes.
The multi-tenant platform showed the database version of the same problem. Row-level security restricts which rows a user sees, but not which columns, so a policy can allow a member to read a row and still expose fields on that row that were meant for administrators. Supabase, the Postgres backend with auth and edge functions, documents policies as row and command scoped, which is exactly why per-column decisions need separate views or privilege grants.
Serverless platform configuration can add its own gap. The report flagged that an origin header only has meaning inside a browser, and that a wildcard deployment setting removes the guarantee entirely for any client that sets the header freely. Vercel, the hosting platform behind Next.js, controls those headers through project configuration.
How to Run This Audit on Your Own Repository
You can repeat the process on your own project in a few hours by cloning it locally, opening the agentic terminal in the project root, and pasting a checklist prompt that demands file paths, exploit reasoning and a written report. The practical steps are straightforward and the order matters.
- Clone the repository to your own machine and install dependencies so the agent can read the full tree, including migrations and environment templates.
2. Confirm the project's license permits study and modification before proceeding. Free and open licenses grant that right, and this workflow assumes you own or are authorized to review the code.
3. Run the audit prompt with a request for severity ranking, verified strengths, exact file references and exploit explanations, and an export to PDF.
4. Review every finding yourself before acting. The agent can flag a pattern that is harmless in your deployment, and the report's own "why this is exploitable" section is what lets you decide.
5. Draft the fix and OpenAI public issue for hardening work, or use a private channel if the issue is exploitable in production today.
Reports took roughly 26 to 28 minutes per project in the demonstration, and the author notes the token cost was high. Treat the time and cost as a budget item, not a footnote.
Reporting Findings Without Breaking the Rules
Responsible reporting means filing hardening findings as public GitHub issues and sending exploitable findings through a private channel the maintainer controls. The video states three rules up front, and they apply to anyone repeating the workflow.
The first rule is that open source is genuinely OpenAI free license grants the right to use, study, modify and run the code, so reading it is not intrusion. The second is that the target must be your own machine. Cloning a repository and testing it locally is legitimate; sending requests to someone's production deployment without permission is a crime in Brazil and a bad idea everywhere. The third is that reporting is part of the work.
The demonstration copies the prompt-generated issue title and body straight into a new GitHub issue, which keeps the report consistent and saves the maintainer from a vague message. Paid penetration testing follows the same etiquette: you ask first, you scope it in writing, and you never touch systems outside the agreement.
What This Audit Does Not Prove
One prompt run against four repositories does not establish that every vibe-coded project is insecure, and it does not prove the agent found everything. The evidence class here is a single developer's demonstration on his own machine, with no independent reproduction of the findings.
The severity counts are the tool's own labels. The multi-tenant project's four high findings were described from the PDF, not verified by reading the merged fixes. The transcript also contains a caveat worth keeping: the author states he did not read the code himself and relied on the report for at least one finding.
A clean report is therefore not a certificate. Passing an audit of this kind means the checklist found nothing in the categories it covers, which is a narrow claim about a specific set of checks on a specific commit.
FAQ
- Is a vibe coding security audit the same as a penetration test? No. A penetration test is performed by a tester with written authorization and a defined scope, often against a running system. A vibe coding security audit is a static review of a cloned codebase with a checklist prompt, which is faster and cheaper but does not exercise live infrastructure.
- Can I run this audit on someone else's project? Only on a local copy you are licensed to study, and only if you report findings through the maintainer's preferred channel. Sending requests to another person's production deployment without permission is unauthorized access, regardless of intent.
- Why did one project have zero critical findings and still matter? Severity labels describe exploitability, not business impact. The multi-tenant report listed four high findings that let one organization reach another organization's secrets, sessions and webhook targets, which is serious even without a critical rating.
- What should I fix first after the report? Start with anything that crosses a tenant or user boundary, then anything that exposes secrets to a client bundle, then input validation. Those three categories account for most of the findings described across the four projects.
- Does this replace reading the authorization code myself? No. The prompt points at the code and explains why a pattern is exploitable, and you still have to confirm the path and decide whether your deployment actually reaches it. Treat the report as a map, not a verdict.
- What does the report include besides the risks? Verified strengths, a methodology section, file-level detail for each finding, an exploitability explanation, and draft issue text for the maintainer. The strengths section is what separates a useful audit from a list of complaints.
- Is the prompt free? The video says the prompt is published free on the author's Substack with no signup required for the material itself. Availability beyond the publication date has not been verified.
- Who is Gustavo Dev Doido in this context? Gustavo Dev Doido is a Brazilian developer educator who teaches full-stack development in Portuguese through long-form YouTube content and paid training programs. His Crazystack Typescript course and the Bootcamp do Dev Doido cover the same territory of building and hardening applications, which is the natural next step after an audit surfaces problems.
- Where can I find the Crazystack program? The Crazystack Typescript course and related training are listed at crazystack.com.br, where the curriculum and enrollment details are published.
Turning a Transcript Into a Readable Audit Write-Up
An audit video contains everything a written report needs, and almost none of it survives in the transcript. Timestamps flatten into run-on sentences, project names get misspelled, and the severity tables disappear entirely, which is why the write-up above reconstructs them from the spoken descriptions.
The same problem applies to any technical video you publish. The reasoning is in the recording, but readers searching for a specific answer cannot watch fourteen minutes to find one paragraph. The knowledge stays trapped in one format.
If you have recorded walkthroughs, lessons or audits like this one, the material already exists. You can turn a YouTube video into an article with Skala Blog by pasting the URL, transcribing the video, and generating a draft you edit before publishing.
The value of a security audit does not stop at the maintainer who reads the issue. Written up carefully, it becomes the reference someone finds months later when they hit the same missing check in their own repository.