DEV Community: Vibe Safe

Your SaaS is deployed. What have you actually verified?

Vibe Safe — Tue, 08 Sep 2026 11:04:13 +0000

The app looks ready to ship.
But there are still some uncomfortable questions:

Did a secret end up in the source code?
Is authentication enforced on the server?
Does the deployed site produce errors you never noticed during development?

I’m building a security scanner alongside a Launch Check to help indie founders investigate those questions before inviting their first users.

The code scanner examines submitted code for potential problems such as hardcoded credentials, SQL injection and cross-site scripting patterns, weak authentication checks, dependency issues, and error-handling mistakes.

You can paste code, upload a file, or scan supported repository files, including private ones. Findings include severity, the affected location, an explanation of the risk, and a suggested before-and-after fix. Each finding should make the next action clear.

Editor, terminal, CI, and MCP integrations support existing workflows. The command-line client sends files individually to a hosted scanning API. That scope matters: scanning a folder doesn’t automatically establish how every component behaves together.

The live website security scan checks the deployment. It looks for issues such as missing security headers, HTTPS problems, exposed paths, unsafe cross-origin settings, and insecure cookie flags.

Then there’s Launch Check, which opens the deployed app in a browser.

You provide a URL and can optionally describe what should work. It navigates accessible pages and collects evidence from the visit: screenshots, page load times, console errors, and failed network requests. The report explains what worked, what needs attention, and suggested next steps.

For example, a page might render its layout while a request fails in the background. Seeing the screenshot alongside the network error gives you something specific to investigate.
Launch Check doesn’t submit forms or click destructive controls. A successful visit therefore doesn’t establish that signup, checkout, or saving data works from beginning to end. Those journeys need their own tests.

The workflow I want to make easier is:
Scan → inspect the evidence → review the fix → apply it → rescan and retest.

Suppose a scan flags a missing authorization check. After changing the code, rescanning can show whether the original finding is still detected. Testing the deployed endpoint answers another question: does it actually reject access from someone who shouldn’t have it?

That means checking anonymous access, a user with insufficient privileges, and a different account trying to access another user’s data. These are concrete authorization tests you can repeat after future changes.

For products that call paid APIs, I’d also check server-side usage limits and spending controls. A valid request can still become expensive when repeated at scale. That needs explicit testing beyond a browser visit.
Scanning uses a hosted service over HTTPS. The published policy states that submitted source code is discarded after processing, isn’t used for model training, and that scan results are retained in your account.

A score is useful for tracking findings. Launch confidence also needs evidence about the checks performed, the fixes made, and the important flows still untested.

I’d love feedback from founders preparing to launch—especially where a finding is wrong, an explanation is unclear, or a check misses something useful.

What would you need to see in a scanner or Launch Check report before trusting it enough to change your code or share your app?

https://www.vibesafe.info/

🚨 Your AI-generated code may be working. That doesn't mean it's safe.

Vibe Safe — Sat, 05 Sep 2026 20:29:09 +0000

We looked at the security risks that repeatedly appear in AI-built applications, and one problem keeps standing out:

Exposed secrets.

API keys. Database credentials. JWT secrets. Service tokens.

They can end up directly inside source code — sometimes in places developers don't expect.

And once a secret is pushed to a public repository, deleting the line later doesn't necessarily mean the secret was never exposed.

What can happen?

🔴 A leaked API key can be abused to access a third-party service.
🔴 Cloud/API accounts can accumulate unexpected charges.
🔴 Database credentials can expose sensitive data.
🔴 Authentication secrets can potentially allow account or application impersonation.

Our VibeSafe research and security checks focus on these exact failure points in AI-generated code.

We found that AI-built applications need more than a simple “it works” test.

They need a “can I safely ship this?” test.

That's why VibeSafe checks for:

• Exposed API keys & secrets
• Database credentials
• JWT/authentication secrets
• SQL injection
• XSS
• Weak authentication
• Missing security controls
• Runtime errors
• Vulnerable dependencies

And importantly, finding a secret isn't the end of the process.

The key should be rotated, removed from the code, and stored securely — for example through environment variables or a proper secrets-management system.

Build fast. Ship safe.

🔗 VibeSafe: https://www.vibesafe.info/

AI can build your checkout. Can it tell you what's unsafe?

Vibe Safe — Thu, 03 Sep 2026 11:01:28 +0000

You can build a working checkout page with AI in an afternoon.

The demo works.
Payments go through.
The UI looks finished.

But there can still be some ugly surprises hiding in the code.

🔴 A live Stripe secret key hardcoded into frontend code

The app works perfectly — until you realize that key has been shipped to every visitor's browser.

🟠 An /admin endpoint without proper authorization

The route works. The API responds. Your AI-generated app considers the job done.

Except someone else can call it too.

That's the problem with a lot of AI-generated code:

It optimizes for "does this work?"

Security requires asking:

"What happens when someone intentionally tries to make this fail?"

That's the gap we're trying to solve with VibeSafe.

VibeSafe scans AI-generated applications for things like:

🔑 Exposed API keys and secrets
🔐 Missing authentication/authorization
🗄️ Database security issues
🚪 Unprotected routes and endpoints
📦 Vulnerable dependencies
⚠️ Security issues that aren't obvious from simply running the app

And instead of dumping a security report full of jargon, it explains the problem in plain English — including what an attacker could potentially do and what you should fix.

Built for developers who can ship with AI, but don't necessarily have a security team reviewing every line.

Try a free scan: vibesafe.info

If you're building with Cursor, Claude, Lovable, Bolt, Replit, or another AI coding tool:

What's the scariest security issue you've discovered in AI-generated code?

Your Stripe key is on GitHub. Do this now, in this order.

Vibe Safe — Fri, 28 Aug 2026 14:32:01 +0000

Deleting the file doesn't help. The key is still live until you rotate it, and it's still readable in git history until you remove it from there too. Here's the order that actually matters.

Step 1 (right now): rotate the key in Stripe

Go to dashboard.stripe.com/apikeys in live mode. Find the exposed secret key, open its overflow menu, and choose Rotate key. In the expiration dropdown, pick Now — not a grace period. A grace period exists to avoid downtime during planned rotations; it does the opposite of what you want during a leak, since it keeps the compromised key valid.

Copy the new key straight into environment variables — server environment, CI secrets, any deployment platform's secret store, never back into a file. Redeploy before you do anything else on this list.

This is the only step that actually disables the key. Everything below matters, but none of it neutralizes the leak by itself.

Step 2: check what happened while it was live

In the Stripe dashboard, check the API request logs for the exposed key — filter by key ID and look for requests you don't recognize, especially from unfamiliar IPs or at odd hours
Check for unexpected refunds, payouts, or customer list queries — a live secret key can read customer records, not just process payments
If anything looks wrong, Stripe support can help assess the blast radius; don't assume silence in the logs means nothing happened, but don't assume the worst either — check first

Step 3: remove it from git history

A key doesn't disappear from a repo when you delete the file and commit — it's still sitting in every commit before that one, retrievable with git log -p or a clone of the repo from before the deletion. If the repo is public or shared, treat the key as burned regardless of what you do next (that's what Step 1 was for), then clean the history so it stops being a liability going forward:

Use git filter-repo (the tool git.com itself now recommends) or BFG Repo-Cleaner to strip the key from every commit, not just the latest one
Force-push the cleaned history, and have every collaborator re-clone rather than pull — a stale local clone will just push the old history back
If the repo is public and has been up for more than a few minutes, assume it's already been scraped by an automated bot regardless of history cleanup — see below

What GitHub does automatically — and what it doesn't

Stripe is one of over 100 partners in GitHub's secret scanning partner program (docs.github.com/en/code-security/secret-scanning/secret-scanning-partnership-program/secret-scanning-partner-program). It runs automatically and free on public repositories: when GitHub detects a live Stripe key pattern in a public push, it notifies Stripe directly, and Stripe can revoke it — sometimes within minutes, before you've even seen the push notification.

Two things this doesn't cover:

Private repositories aren't scanned by default. A key in a private repo can sit exposed indefinitely to anyone with access — a contractor after their contract ends, a compromised collaborator account, a fork nobody remembers exists.
There's still a window. Detection isn't instant, and a scraper watching public commits in real time can beat GitHub's own notification to Stripe. Rotating yourself in Step 1 is what closes that window — don't wait to see if GitHub catches it first.

Prevent the next one

Use restricted keys scoped to only what each service needs — a webhook handler that only needs to read charges shouldn't hold the full secret key
Add .env to .gitignore before the first commit, not after the first leak
Scan before you push, not after GitHub or a customer tells you

FAQ

Does GitHub automatically revoke a leaked Stripe key?
Stripe is a partner in GitHub's secret scanning partner program, which runs automatically and free on public repositories. This does not cover private repositories, and there's still a window between the push and detection where the key is live.

Is deleting the file with the key enough?
No. Deleting the file and committing that change leaves the key readable in git history via git log or git show. The key must be rotated in the Stripe dashboard regardless of what you do to the repository.

Are restricted keys safer than the full secret key?
Yes. A restricted key scoped to only the operations your app needs limits what an attacker can do if it leaks. It doesn't prevent the leak, but it shrinks the blast radius.

"I checked 25 AI-built apps for security holes. The same 5 mistakes, every time."

Vibe Safe — Tue, 14 Jul 2026 09:16:04 +0000

I've spent the last few weeks looking at security on apps built with AI tools — Lovable, Bolt, Cursor, Replit, v0. Different people, different products, different stacks. And yet the same five holes show up almost every single time.

None of this is because the tools are bad. It's because an AI coding assistant optimizes for "make the demo work," not "make it safe to put on the internet." Those are different goals, and the gap between them is where you get owned.

Here are the five that keep coming up, what they look like, and how to check your own app.

1. Secret keys sitting in the frontend bundle

The most common one, by a mile. The AI needs to call an API, so it drops the key straight into client-side code:

// This ships to every visitor's browser
const supabase = createClient(url, SERVICE_ROLE_KEY);
const stripe = new Stripe("sk_live_51H...");

Anything in your frontend bundle is public. Open DevTools → Sources, or just view-source, and it's right there. A service_role key or an sk_live_ secret in the browser means anyone can read/write your whole database or hit your payment provider as you.

The nuance that trips people up: not every key is a secret. A Supabase anon key (sb_publishable_...), a Firebase apiKey, or a Stripe publishable key (pk_live_) are designed to be public — they're safe in the frontend as long as your access rules are correct (see #2). The dangerous ones are service_role, sk_live_/sk_test_, and anything labeled "secret."

Check: search your bundle for service_role, sk_live, SECRET, PRIVATE_KEY. If a truly secret key is there, rotate it immediately and move it server-side.

2. Supabase Row Level Security never got turned on

This is the big one for anything using Supabase. You create a profiles or orders table, the app works great in testing… because RLS is off, so every row is readable by anyone with the (public) anon key.

-- Table created, RLS never enabled = the whole table is public
create table orders (id uuid, user_id uuid, total numeric, card_last4 text);

Since the anon key is in the frontend (correctly!), a stranger can open a console and run:

const { data } = await supabase.from('orders').select('*'); // everyone's orders

Check: in the Supabase dashboard, every table under public should say RLS enabled, with policies that actually scope rows to the user (auth.uid() = user_id). "RLS is on" is not enough — a policy of true is the same as off. This exact class of bug is behind a lot of the Lovable/Supabase data leaks people have written up.

3. Auth checks that only exist in the UI

The app hides the admin button unless you're an admin. Feels secure. But the route underneath has no check:

// Frontend hides the link... but the endpoint is wide open
app.post('/api/admin/delete-user', async (req, res) => {
  await db.deleteUser(req.body.id); // no auth check at all
});

Hiding a button is not access control. Anyone can call the endpoint directly with curl.

Check: for every sensitive action (delete, refund, change role, read other users' data), confirm the server verifies who's calling and whether they're allowed — not just the UI.

4. Storage buckets left public

AI tools love to set a storage bucket to public so image uploads "just work." Then user IDs, receipts, or private uploads are all listable by URL.

Check: in Supabase/Firebase storage, buckets holding anything user-specific should be private, served through signed URLs — not public with guessable paths.

5. No security headers on the deployed site

Missing Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, etc. On its own this is lower severity, but it's the difference between a clickjacking/XSS attempt bouncing off and landing.

Check: run your deployed URL through any headers checker, or your browser's DevTools → Network → click the document → Response Headers.

How to actually check all of this

You can go through the list above by hand — and honestly you should understand each one. But when you want a faster pass, there's now a whole category of scanners built specifically for AI-generated apps. They fall into two buckets:

URL scanners that probe your deployed app (good when you don't have/want to share code)
Code-aware scanners that read your source

I actually wrote up an honest side-by-side of the main options — VibeSafe, Vibe App Scanner, CheckVibe, Snyk, Semgrep, AuditYourApp — including which one fits which situation and where each falls short: Best Vibe Coding Security Scanners (2026).

Full disclosure: I work on VibeSafe, one of the tools in that comparison — it scans both code and your live URL and explains issues in plain English, which is why I reach for it. But the comparison is deliberately fair, and for a lot of people Snyk or a free URL scan is the right call. Use whatever gets you to check before you launch instead of after.

The one takeaway

If you built something with AI and you only do one thing from this post: check that your Supabase tables have real RLS policies and that no service_role/sk_live_ key is in your frontend. Those two cover the majority of the serious breaches I've seen in vibe-coded apps.

Ship fast — just check the locks before you hand out the address.

What have you run into on AI-built apps? Drop the weirdest security thing you've found in the comments.

🚀 New in VibeSafe: Launch Check

Vibe Safe — Tue, 07 Jul 2026 06:02:49 +0000

Your app looks finished. But does it actually work when a real person uses it?

Before you share your app with users, clients, or investors — let VibeSafe test it for you. Paste your URL and our AI opens your live app like a real visitor:

✅ Clicks through your pages
✅ Captures screenshots of what users actually see
✅ Catches broken buttons, errors, and slow screens
✅ Gives you a clear launch-readiness score — with the exact fixes, in plain English

No more "it worked on my machine" surprises. Find the problems before your users do.

👉 Try it free at vibesafe.info — built for founders shipping AI-made apps.

vibecoding #buildinpublic #indiehackers #startup #nocode #saas #AI

Your AI-built app may look ready… until a secret key is sitting in plain sight

Vibe Safe — Fri, 03 Jul 2026 07:14:08 +0000

This is the part many new AI builders miss.

The app can run perfectly.
The dashboard can load.
The buttons can work.
The deployment can look successful.

But inside the code, there may still be something dangerous:

A secret key exposed directly in the frontend.

That one small mistake can become a big problem.

It can lead to:

Exposed API access.
Unexpected billing charges.
Private data risks.
Broken user trust.
Security issues before the app even gets real users.

The scary part is that many AI-generated apps do not “look broken” when this happens.

The code may still work.

That is why I am building VibeSafe.

VibeSafe scans AI-built apps for issues like exposed keys, runtime errors, missing packages, weak security patterns, and risky code before launch.

The goal is simple:

Not another confusing security tool.
Not a long report full of jargon.
Just a clear warning before you ship.

Something a beginner can understand:

What is wrong
Why it matters
What to fix next

The image below shows the kind of problem VibeSafe is designed to catch before launch: a hardcoded secret key and a low safety score.

AI is making app development faster than ever.

Now we need to make checking those apps easier too.

Build fast. Ship safe.

Question for developers:
What is the first security check every AI-built app should pass before launch?

Your AI-Built App May Look Ready — But Is It Really Safe?

Vibe Safe — Mon, 29 Jun 2026 15:59:36 +0000

AI tools are helping people build websites and apps faster than ever.

You can create a landing page, dashboard, MVP, or full app much quicker than before.

That is exciting.

But there is one thing many beginners forget:

Just because an app looks ready does not always mean the code is safe.

The hidden problem

When we build fast, we can easily miss important checks.

Some common problems are:

exposed API keys
broken functions
missing packages
runtime errors
weak security rules
forms that do not work properly
code that works in preview but breaks after launch

For experienced developers, these issues may be easier to find.

But for beginners, founders, students, freelancers, and small business owners, these errors can be confusing.

Your website may look fine on the screen.

The design may look good.

The button may work.

But behind the scenes, there may still be hidden problems.

Why this matters

Many people are now using AI to build their first website or app.

That is a great thing because more people can turn their ideas into real products.

But launching without checking the code can create problems later.

A small hidden issue can cause:

broken pages
failed forms
exposed private information
security risks
bad user experience
stress after launch

That is why checking before launch is important.

A simple checklist before launching

Before publishing your website or app, ask yourself:

Are all forms working correctly?
Are there any visible API keys in the code?
Are all required packages installed?
Are there any console errors?
Are pages loading properly?
Are buttons and links working?
Are user data and private settings protected?

These checks may sound technical, but they are very important.

What I am building

I am building VibeSafe, a simple code scanning dashboard for AI-built websites and apps.

The goal is to help users check their code before launch and understand the results in plain English.

No confusing technical language.

No complicated reports.

Just simple feedback that helps users understand what may need fixing.

The mission

The mission is simple:

Build fast. Ship safe.

AI can help us build faster.

But before launching, we should still take a moment to check if the project is safe, stable, and ready.

I would love your feedback

If you build websites, apps, or MVPs, what is the first thing you usually check before launch?

And what would you want a beginner-friendly scanner to check for you?

I’m building VibeSafe and would love honest feedback.

Website: vibesafe.info

“What Beginners Should Check Before Launching an AI-Built App”

Vibe Safe — Fri, 26 Jun 2026 16:14:52 +0000

AI tools have made it easier than ever to build apps quickly.

A founder, student, freelancer, or non-technical creator can now create a landing page, dashboard, MVP, or even a full SaaS idea much faster than before. That is exciting — but it also creates a new problem.

Just because an app works does not always mean it is safe.

When we are building fast, it is easy to focus only on the visible parts:

Does the button work?
Does the page look good?
Does the login open?
Does the dashboard load?
Can I share the link?

But security problems are often hidden. The app may look finished, while small mistakes are sitting quietly in the background.

For beginners, these are some of the most important checks before launch.

1. Check if your API keys are exposed

One of the most common mistakes is accidentally placing secret keys inside frontend code, public repositories, or shared files.

If an API key is visible to users, it can potentially be copied and misused.

Before launch, check:

Are API keys stored in environment variables?
Are secret keys kept out of frontend code?
Is your .env file ignored in Git?
Did you accidentally upload credentials to GitHub?

A simple rule: if the browser can see it, users can see it too.

2. Check your database access rules

Many apps use tools like Supabase, Firebase, or other backend platforms. These tools are powerful, but they still need correct access rules.

A common beginner mistake is assuming the database is private by default.

Before launch, check:

Can one user see another user’s data?
Are database rules enabled?
Are tables protected?
Can users only access their own records?
Are admin-only actions actually restricted?

This matters because user data is one of the most important things your app must protect.

3. Check authentication and user roles

An app also needs to know what each user is allowed to do.

For example:

A normal user should not access admin pages.
One customer should not see another customer’s dashboard.
A logged-out user should not access private routes.
Role checks should happen on the backend, not only in the frontend.

Frontend hiding is not real security. If something is sensitive, protect it on the server side too.

4. Check for broken links, missing packages, and runtime errors

Security is important, but stability matters too.

Before sharing your app publicly, check:

Are there console errors?
Are all packages installed correctly?
Are there broken pages?
Does the app work on mobile?
Does the form submit correctly?
Do error messages expose technical details?

Small errors can reduce trust quickly, especially if this is your first impression with users.

5. Check what happens when something goes wrong

Many beginners test only the happy path.

But real users do unexpected things.

They refresh pages, enter wrong data, upload large files, use weak passwords, click buttons twice, or leave forms empty.

Before launch, test:

Wrong email or password
Empty form fields
Slow internet
Failed payment
Expired session
Unauthorized page access
Invalid file uploads

A safer app is not just one that works. It is one that handles mistakes properly.

6. Check AI-generated code before trusting it

AI can help us build faster, but it should not be treated like a final security reviewer.

AI-generated code may still contain:

weak access control
exposed secrets
missing validation
insecure database rules
outdated package suggestions
logic mistakes

AI is a great assistant, but human review and security checks are still needed.

My simple launch checklist

Before launching any AI-built app, I would check:

No API keys in frontend code
No secrets uploaded to GitHub
Database access rules are enabled
Users can only access their own data
Admin routes are protected
Forms validate user input
Error messages do not leak sensitive details
Dependencies are checked
App works on mobile
Basic security scan is done before launch

Final thought

Building fast is powerful.

But launching safely is what protects your users, your reputation, and your future business.

I am currently exploring this problem while working on VibeSafe, a project focused on helping beginners understand app security issues in simple language.

I would love to learn from the DEV community:

What is one security mistake you think every beginner should check before launching an app?

# Hi DEV Community 👋 I’m New Here

Vibe Safe — Fri, 26 Jun 2026 15:10:42 +0000

Hi everyone,

I’m excited to join the DEV community.

I’m currently learning and building around web development, AI tools, SaaS ideas, and software security. My main interest is helping beginners and non-technical founders understand how to build apps faster, but also make sure they are safe before launch.

I’m also working on a project called VibeSafe, focused on making app security easier to understand in simple language.

I’m here to learn, share my journey, ask questions, and connect with other builders, developers, and founders.

A few things I’m interested in:

AI-built apps
Web app security
SaaS tools
No-code and low-code apps
Beginner-friendly development tips
Startup and product-building lessons

I’m looking forward to learning from this community and sharing useful things along the way.

What is one beginner-friendly security tip you think every new app builder should know?