Vibe Safe
The security scanner for AI-built apps
You ask your AI coding tool to fix a security issue.
It updates the code. The app still works. The warning disappears.
Would you feel comfortable putting real customer data into it?
I’m building VibeSafe, and this is a question I’m thinking about: how can a founder understand what changed—and what still needs checking?
Here’s an example from the code shown in our demo screenshots.
A database query inserts user input directly into the query text. VibeSafe flags the risk and explains why it matters. A suggested change separates the input from the query using parameters.
That gives you something specific to review. But applying a suggested fix doesn’t establish that the whole app is secure.
Our post-fix screen labels its updated score “Estimated” and asks you to rescan. Even a new scan has limits: you still need to test how your app behaves.
One practical check for an app with private user data:
Create two test accounts in your own app. Add a private record under account A. Check whether account B can access or change it when your permissions say it shouldn’t.
A working login screen alone doesn’t answer that question.
VibeSafe helps flag potential code security issues and explains findings and suggested fixes in plain English. It’s a starting point for review, not a guarantee that an app is safe.
I’m looking for five people building with Lovable, Bolt, Cursor or Replit to try it on their own code and tell me where the results help—or leave them confused.
You can explore it and create a free account here:
https://www.vibesafe.info/
Before you ship, what evidence makes you trust a security fix: a rescan, a repeatable test, or another developer’s review?
One thing I’ve learned while building VibeSafe:
Getting an AI-built app to work is surprisingly easy.
Knowing whether it’s safe is much harder.
Before launching, I’d personally check these 7 things:
1. 🔑 Secrets
Search your entire codebase for API keys, tokens, passwords, and database credentials.
2. 🔐 Authentication
Try accessing protected pages without logging in.
3. 🗄️ Database access
Check whether a user can access another user's data by simply changing an ID.
4. 🌐 API endpoints
Look for endpoints that perform sensitive actions without proper authorization.
5. 📦 Dependencies
Check what packages the AI added. You might not know what you're actually shipping.
6. 🐛 Error messages
Production errors shouldn't expose stack traces, database details, or internal paths.
7. 🤖 Don't trust the AI's "done."
Ask another tool—or another person—to review the code from an attacker's perspective.
The interesting part?
A founder can spend weeks building features and still miss one tiny security mistake that takes an attacker seconds to find.
That's actually why we're building VibeSafe: to give indie hackers a security checkpoint between:
“AI built it” → “I'm ready to ship it.”
Curious what other founders do:
What's your security checklist before launching an AI-built SaaS?
Even if it's just one thing, share it below. I'd love to turn the answers into a practical indie-hacker security checklist.
Build fast. Ship safe.
-
1One thing I’d add is cost abuse, especially for AI products. A request can be technically valid but still become very expensive if someone automates it. I now think rate limits, credit checks before calling the model API, and server-side usage validation should be part of the security checklist too. For AI image/video products, API cost protection can be almost as important as protecting user data.
-
1
Great point. Cost abuse is an overlooked security risk for AI products. Rate limits, usage validation, credit checks, and spending caps should be part of every pre-launch security check. We’re exploring how VibeSafe can identify these risks too.
-
-
1Stress-testing an AI-built product by actively attempting to break it is the vital transition step between rapid prototyping and production readiness. Moving beyond initial feature validation to deliberately probe edge cases, prompt injection vulnerabilities, and API latency ensures that an app won't collapse under real-world usage or leave its builder with catastrophic token bills.
-
-
1
Yes. VibeSafe works with private GitHub repos, Cursor, and CI/CD.
🔒 Private repos: Connect GitHub and scan private repositories.
🖥️ Cursor: Use the VibeSafe Cursor/VS Code extension or MCP to scan while you code.
⚙️ CI/CD: Run VibeSafe from the CLI or GitHub Action to scan automatically on pull requests.
The goal is to catch security issues where you already work, rather than making you move your code into another workflow.
And for sensitive code, we recommend using the appropriate privacy/security settings and permissions for your environment.
-
Building VibeSafe has taught me something I didn't expect:
Finding security issues is only half the problem. Helping people understand what to do next is just as important.
Our first approach was simple — scan the code, find issues, and show the results.
But as the scanner became more powerful, the results became more complicated.
A developer could see:
🔴 Critical issues
🟠 High-risk issues
🟡 Medium issues
📁 File locations
💻 Code snippets
🛠️ Recommended fixes
Technically, that's useful.
But for someone who isn't a security expert, it can quickly become overwhelming.
So we're changing the experience.
Instead of simply saying:
"You have 8 security issues."
We want VibeSafe to answer three questions:
1. What is wrong?
2. Why does it matter?
3. How do I fix it?
And then make it easy to fix → rescan → verify.
That's becoming an important part of what VibeSafe is about.
AI makes it incredibly easy to build an app quickly.
But getting from "it works" to "it's safe to ship" is a different problem.
That's the problem I'm trying to solve.
I'd love feedback from other founders:
When a security tool gives you a long list of issues, what information do you actually want to see first?
-
1I would show the release decision first, not the issue list: ‘safe to ship,’ ‘ship with accepted exceptions,’ or ‘block release,’ with the exact evidence behind that decision. Severity alone is hard to act on because eight findings can mean one real release blocker or eight low-context warnings. Then keep the fix → rescan → verify loop, but preserve which code version was scanned so the result remains reproducible after the next AI-generated change.
-
1
This is a really useful perspective. I especially like the idea of showing the release decision first rather than making users interpret a list of severity levels.
“Safe to ship / Ship with exceptions / Block release” could make the result much more actionable.
And the reproducibility point is important too. With AI-generated changes happening so frequently, knowing exactly which version was scanned and being able to compare the result after a rescan would make the fix → rescan → verify loop much more meaningful.
I’m going to add this to our product thinking. Thanks for the detailed feedback! 🙌
-
1Glad it's useful. I'd tighten my earlier wording to 'passes these release checks,' with the commit and scan coverage visible. A clean scan doesn't establish that the whole app is safe. That narrower label still helps someone decide what to do next without overstating what the scanner verified.
-
-
I've been building VibeSafe because I kept seeing the same pattern with AI-built apps:
The app works.
The UI looks good.
The deployment succeeds.
But what's actually happening underneath?
Are secrets exposed?
Is authentication implemented correctly?
Are there insecure endpoints?
Are there runtime errors?
Does the deployed app actually behave the way the builder thinks it does?
That's what we're trying to solve with VibeSafe.
We're currently testing a workflow that can scan code/files/GitHub, test a live website, and run Launch Check against the actual application.
I'm still figuring out what the minimum useful security check for an AI-built app should be.
If you build with Cursor, Claude, ChatGPT, Lovable, Bolt, Replit, etc. — what's the security check you wish existed before you hit “deploy”?
Hey Indie Hackers 👋
I’m building VibeSafe, a security scanner for apps built with AI.
AI makes it incredibly easy to build and launch software, but it’s also easy to accidentally ship security issues you didn’t notice.
VibeSafe helps AI builders find potential security problems before they ship.
I’m also working on VibeSafe Builder, where the goal is to make AI-powered building faster and more practical.
The bigger vision is simple:
Build with AI → Scan → Fix → Ship safely.
We’re still early, and I’d love feedback from other indie hackers and people who are vibe coding.
What’s the biggest security problem you’ve encountered when building with AI?
I’d love to hear what you think. 🚀
Website: https://www.vibesafe.info/
-
1
The recurring-use question seems important.
Are builders running VibeSafe on every release, or mainly before launch?
-
1
Ideally, both. VibeSafe can be used before launch for a deeper security check, but the bigger value is running it on every meaningful release so new AI-generated changes don’t introduce vulnerabilities, exposed secrets, or runtime issues. Think of it as a safety check in the development workflow—not just a final pre-launch audit.
-
1The recurring workflow is the more interesting test. I’d be curious to dig into what actual usage looks like once people start running it repeatedly. Happy to continue privately — what’s the best email to reach you on?
-
-
2 Comments
For me, it would take evidence that the important parts of the app behave correctly. A working demo and a good scanner score are useful, but I’d want to understand what was tested.
Before bringing in paying customers, I’d ask:
Can users access only what they’re supposed to?
I’d create two test accounts and check whether one can see or change the other’s private information. I’d also check that a normal user cannot perform admin actions. Hiding an admin button isn’t enough—the server must enforce the restriction.
Are secrets and customer data protected?
I’d check that private API keys and database credentials aren’t exposed in browser code or public files, and that database permissions match what each user should be allowed to do.
Does the payment flow work beyond a successful checkout?
I’d test failed payments, cancellations, and repeated payment notifications. Paid access should depend on verified payment, and processing the same notification twice shouldn’t create duplicate charges or benefits.
Were the security fixes actually verified?
If an AI tool changes something, I’d review the change, rerun the scan, and repeat the test that exposed the problem. A higher score doesn’t establish that the underlying issue is resolved.
Will I notice a failure and be able to recover?
I’d want error alerts, a working support contact, and a way to roll back a bad release. If the app stores customer data, I’d also want a backup I’ve successfully tested restoring.
The depth of review should match the stakes. An app handling sensitive information or complicated permissions deserves an experienced professional’s review.
This is part of what I’m working on with VibeSafe: helping founders find potential issues and understand what to investigate. Scanning supports that process; it doesn’t replace testing or professional judgment.
I’d feel ready when the critical flows had been tested, serious findings had been addressed and checked, and the remaining risks were understood. No tool can promise zero risk.
What’s the one check you would never skip before accepting a paying customer?