DEV Community: kg8888

I Built a Security Scanner for AI Apps — Then I Ran It on My Own Site

kg8888 — Sun, 05 Jul 2026 17:50:08 +0000

I built VibeSafe — a 24-check security scanner for apps made with AI coding tools (Cursor, Lovable, Bolt, v0, Replit).

The idea came from a pattern I kept seeing: AI tools produce code that works, but rarely code that's secure. Hardcoded API keys, disabled Row Level Security, missing CSP headers, exposed .env files. Same issues, different apps.

Before writing a line of scanner code, I manually audited 5 real vibe-coded apps:

5/5 had at least one critical vulnerability
3/5 had exposed API keys in frontend JavaScript
4/5 had Row Level Security completely disabled
1/5 had their entire database publicly readable

Every founder was shocked. None of them knew.

The Dogfood Test

So I built the scanner — 24 checks across pre-launch source code and post-launch live URLs.

Then I ran it on my own site. The worst possible outcome:

Zero issues. Clean scan. Trust badge earned.

Not because I'm a security expert. Because I built the scanner to catch exactly what I knew AI tools get wrong — and I fixed each issue before shipping.

What the Scanner Checks (24 total)

Pre-launch (10 checks — source code):

Exposed secrets, SQL injection, Supabase RLS, Firebase rules
Hardcoded credentials, unprotected API routes, Stripe webhook verification
Dependency CVE audit, DB config exposure

Post-launch (14 checks — live URL):

SSL/TLS, security headers, exposed files, JS bundle secrets
CORS, rate limiting, data breach check, source map exposure
Cookie security, robots.txt analysis, subdomain discovery
Supply chain / SBOM check, trust badge

Why I'm Posting This

I'm running a launch week. Everything is 40% off with code LAUNCH40:

Product	Regular	Launch Price
Post-Launch Scan (14 URL checks)	$19	$11
Pre-Launch Audit (10 repo checks)	$39	$23
Full Bundle (all 24 checks)	$49	$29
Continuous Protection (weekly)	$39/mo	$23/mo

One-time pricing, plain-English reports with exact fixes.

→ vibesafe.store

Quick check for your own codebase:

grep -r "eyJ" --include="*.js" --include="*.ts" .     finds JWT tokens
grep -r "api_key\|password\|secret" --include="*.js" .finds hardcoded creds

You might be surprised what you find.

Why Most SaaS Referral Programs Fail (And What to Do About It)

kg8888 — Thu, 02 Jul 2026 11:55:40 +0000

Every SaaS founder knows word-of-mouth is the cheapest, highest-converting channel. Happy customers tell other founders. A single recommendation can bring in a customer who stays for years.

Yet most referral programs never take off.

Not because the idea is wrong — but because the execution is too heavy. You need unique tracking links, click counting, conversion attribution, payout logic, a UI for users to generate their own links, and a way to verify that each referral actually turned into a paying customer. That's weeks of engineering time — time most early-stage teams don't have.

What if the plumbing already existed?

I've been working on a small open-source project called RefLinkGen that takes a different approach. Instead of building another dashboard that sits alongside your Stripe account, it works through Stripe. When someone refers a friend, the system creates a real Stripe promotion code. When the friend checks out and applies that code, Stripe records the discount — and a webhook tells the system to credit the referrer.

The entire loop looks like this:

User shares a link.
Friend clicks it and goes to checkout with a promo code.
Stripe handles the discount. The system handles the attribution.
No manual coupon creation. No separate payment processing. No reconciling spreadsheets at the end of the month.

Who benefits from this?

Indie hackers and solo founders – You have product-market fit but no time to build a referral system from scratch. Two lines of embed code and you're live.
Small SaaS teams – You want a measurable growth loop that your team can track without adding a new tool to your stack.
Product managers testing growth channels – You need an API you can call programmatically, not a feature request that takes three sprints.
Anyone selling through Stripe – If your payment flow already runs on Stripe, adding referral tracking becomes a configuration step, not a project.
Why this matters for growth

Most referral tools charge a percentage of your revenue or a monthly fee that's higher than your current MRR. When you're pre-revenue or early-stage, that cost kills the experiment before it starts.

The alternative has always been "build it yourself" — which means time away from your product.

A lightweight, self-hostable, Stripe-native approach removes both barriers. You can test whether referrals work for your audience without committing engineering resources or a monthly budget. And if the channel proves itself, you scale it — on your own terms.

No lock-in. No revenue share. Just a tool that does one thing: turn happy customers into a reliable acquisition channel.

I wrote more about the build process and the design decisions on my GitHub . If you've been thinking about adding a referral program but haven't found the time, it's worth a look.

I Scanned 5 Real Vibe-Coded Apps With a Security Scanner — Here's What I Found

kg8888 — Tue, 23 Jun 2026 12:22:27 +0000

I've been building VibeSafe — a security scanner specifically for AI-generated code. So I decided to put it to work on real apps.

I grabbed 5 vibe-coded products from the Vibe Coding Showcase and ran them through the full audit.

The results are worse than I expected.

Executive Summary

5 out of 5 apps had security issues. Zero had a Content Security Policy. 33 total findings.

Severity	Count
🔴 CRITICAL	6
🟠 HIGH	9
🟡 MEDIUM	18
TOTAL	33

1. NewMom.help — Bolt + Supabase

Built by a non-technical founder. Maternal health platform. 1M+ impressions at launch.

🔴 CRITICAL — VibeSafe verdict: "Your app is leaking data"

Category	Status	Detail
🔴 Exposed Files	FAIL	`.env` and `.env.local` publicly accessible — anyone can grab credentials
🔴 Source Control	FAIL	`/.git/` exposed — full repo history downloadable
🟠 CSP Header	FAIL	Content-Security-Policy missing — zero XSS protection
🟠 HSTS Header	FAIL	Strict-Transport-Security missing — SSL downgrade possible
🟡 X-Frame-Options	FAIL	Missing — clickjacking vulnerability
🟡 X-Content-Type-Options	FAIL	Missing — MIME-sniffing attacks possible
🟡 Referrer-Policy	FAIL	Missing — referrer leakage
🟡 Auth Rate Limiting	WARN	`/api/auth/login` detected — no rate limiting

11 issues found (4 critical, 2 high, 3 medium, 2 low)

2. Disko.is — Replit + React

SMS loyalty platform with member data. Built by a solo founder in Iceland.

🔴 CRITICAL — Same pattern as NewMom

Category	Status	Detail
🔴 Exposed Files	FAIL	`.env` and `.env.local` publicly accessible
🔴 Source Control	FAIL	`/.git/` exposed — full repo downloadable
🟠 CSP Header	FAIL	Content-Security-Policy missing
🟠 HSTS Header	FAIL	Strict-Transport-Security missing
🟡 X-Frame-Options	FAIL	Missing — clickjackable
🟡 X-Content-Type-Options	FAIL	Missing
🟡 Referrer-Policy	FAIL	Missing
🟡 Auth Rate Limiting	WARN	Auth endpoint without protection

11 issues found (4 critical, 2 high, 3 medium, 2 low)

3. AltCloud.dev — Lovable + Bolt + Supabase

Built by an experienced CTO. SaaS platform.

🔴 CRITICAL — Git history and server internals exposed

Category	Status	Detail
🔴 Source Control	FAIL	`/.git/` exposed — full repo leaked
🟠 CSP Header	FAIL	Content-Security-Policy missing
🟠 Server Internals	FAIL	`__pycache__/` directory exposed publicly
🟡 X-Frame-Options	FAIL	Missing — clickjackable
🟡 Auth Rate Limiting	WARN	Auth endpoint without rate limiting

Notable: This was the only app that handled environment variables properly in source code — no committed .env files. But the live site was leaking git history and Python cache directories.

7 issues found (2 critical, 2 high, 2 medium, 1 low)

4. SleepingBaby.info — Cursor + Next.js + MongoDB

Parenting app by a solo developer. Entire app built in 450 tokens.

🟠 HIGH RISK — Best of the bunch, but still gaps

Category	Status	Detail
✅ SSL/TLS	PASS	Valid certificate
✅ .env Files	PASS	No exposed environment files
✅ .git Directory	PASS	Not exposed
🟠 CSP Header	FAIL	Content-Security-Policy missing — zero XSS protection
🟡 X-Frame-Options	FAIL	Missing — clickjackable
🟡 X-Content-Type-Options	FAIL	Missing — MIME-sniffing risk
🟡 Auth Rate Limiting	FAIL	`/api/auth/signin` — no rate limiting, brute-force possible

6 issues found (0 critical, 1 high, 3 medium, 2 low)

5. RemedyHunt.com — Bolt + Supabase + Netlify

Live product on Netlify. Built by a non-technical founder.

🔴 CRITICAL — SSL certificate invalid, browser blocks the site

Category	Status	Detail
🔴 SSL/TLS	FAIL	Certificate is INVALID — certificate verify failed. Browsers show a security warning
🟡 Accessibility	FAIL	Could not check headers — no valid HTTPS connection

2 issues found (1 critical, 0 high, 1 medium)

The Common Thread

Issue	Apps Affected
❌ No Content Security Policy (XSS protection)	5/5 — 100%
❌ No X-Frame-Options (clickjacking)	5/5 — 100%
❌ No X-Content-Type-Options (MIME sniffing)	4/5 — 80%
❌ No Referrer-Policy (referrer leakage)	4/5 — 80%
❌ Auth endpoint without rate limiting	4/5 — 80%
❌ No or weak HSTS (SSL downgrade)	3/5 — 60%
❌ `.env` or `.git/` exposed publicly	3/5 — 60%
❌ No valid SSL certificate	1/5 — 20%

The Good News

Not all vibe-coded apps are insecure. The source code scan found some bright spots:

Project	Stack	Issues	Notes
Obertura	Vite + TypeScript (chess app)	0	✅ Clean scan. Earned the trust badge
Autobot	Node.js CLI + Playwright	0	✅ Clean scan
Interior Planner	Next.js + Drizzle + Vercel Blob	10	Had proper auth system, env vars, `.env.example`. Issues were missing route auth — fixable in an afternoon

Some builders do think about security. But the majority ship fast and find out later.

The Fix

Problem	Fix	Time
No CSP	`Content-Security-Policy: default-src 'self'`	1 minute
No X-Frame-Options	`X-Frame-Options: DENY`	1 minute
No HSTS	`Strict-Transport-Security: max-age=31536000`	1 minute
Exposed .env	Add `.env` to `.gitignore`, block at host level	1 minute
Exposed .git	Block `/.git/` in hosting config	1 minute
No rate limiting	Add middleware (express-rate-limit, @upstash/ratelimit)	10 minutes

That's 15 minutes of work to fix 90% of what we found.

Why This Matters

These aren't weekend experiments. They're live products with real users:

A maternal health platform with actual mothers depending on it
An SMS loyalty club with member data
A parenting app with user accounts
A SaaS platform
A production app on Netlify

They're all clickjackable. All have zero XSS protection. Three are leaking credentials to the public internet right now.

Scanned with VibeSafe v1.0. 16 checks: SSL/TLS, security headers (CSP, HSTS, XFO, XCTO, Referrer-Policy), exposed files (.env, .git), CORS, JS bundle secrets, rate limiting. Source code: Trufflehog secrets, Semgrep static analysis, Supabase RLS, Firebase rules, hardcoded credentials, missing auth, Stripe webhook verification, SQL injection.

The Security Checklist Every Vibe Coder Needs Before Launch

kg8888 — Sun, 21 Jun 2026 15:44:41 +0000

You shipped something. It works. Users are signing up.

And somewhere in your codebase, there's a Firebase rule that reads allow read, write: if true.

This is not a hypothetical. In March 2026, a quit-porn app called Quittr - 600,000 users, $1.1M in total revenue - was found to have every user record publicly readable. Ages. Emotional triggers. Personal confessions. The fix would have taken five minutes. The founders didn't know it was needed.

If you built your app with Lovable, Bolt, Cursor, v0, Replit, or any AI coding tool, this post is for you.

Why vibe-coded apps are uniquely vulnerable

AI coding tools optimize for "it works." They generate functional code fast, and that's genuinely useful. But security is almost never functional - a broken auth check doesn't throw an error, it just quietly lets the wrong person in.

The result is a specific, predictable set of mistakes. Not random vulnerabilities - the same four or five patterns, repeated across tools, stacks, and founders. A 2026 OX Security study found 62% of AI-generated code ships with vulnerabilities. CVE-2025-48757 (February 2026) affected 170+ Lovable apps by exploiting the same RLS misconfiguration pattern the tool had generated thousands of times.

These are factory-produced vulnerabilities. Which means they're findable and fixable before you ship.

The 8 most common vulnerabilities we see

1. Exposed API keys and secrets

AI assistants embed API keys directly in frontend code because it's the path of least resistance. The result: your OpenAI key, Stripe live key, or Supabase service-role key is readable by anyone who opens DevTools ? Sources on your deployed site.

Check: Build your app locally and search the output:

ash grep -r "sk_live|service_role|OPENAI_API" ./dist

If anything shows up, it's exposed in production too.

2. Supabase Row Level Security disabled

RLS is what prevents one user from reading another user's data - or an unauthenticated request from reading all users' data. When AI-generated Supabase code throws a permission error, the model's fix is to disable RLS on the table. Error goes away. Vulnerability ships.

CVE-2025-48757 exploited this exact pattern: the public anon key (which is embedded in your client by design) was enough to dump entire tables because RLS wasn't there to stop it.

Check: Open your Supabase dashboard ? Table Editor ? each table should show RLS as enabled with at least one policy defined.

3. Firebase insecure rules

Firebase ships new projects in "test mode" with rules that allow anyone to read and write everything: allow read, write: if true. These rules are meant to be temporary. AI tools generate Firebase code that assumes they've been updated. They often haven't.

Check: Firebase Console ? your database ? Rules tab. If you see if true anywhere, change it now.

4. Unprotected API routes

AI tools generate API endpoints. They don't always generate the middleware that checks whether the caller is authenticated. The result: a /api/users endpoint that returns your full user list to any unauthenticated GET request.

Check: Test your API routes with no auth header or cookie using curl or a tool like Insomnia. If you get data back, the route is open.

5. Stripe webhook bypass

Stripe sends webhooks to your server when payments happen. If you don't verify the webhook signature, anyone can POST to your endpoint and fake a successful payment.

Check: Your webhook handler should call stripe.webhooks.constructEvent(body, sig, process.env.STRIPE_WEBHOOK_SECRET). If it doesn't, it's unprotected.

6. SQL injection

AI-generated database queries sometimes concatenate user input directly into query strings. This is the oldest vulnerability in web development and it's still showing up in vibe-coded apps.

Check: Search your codebase for string concatenation in database queries: anything like SELECT * FROM users WHERE id = is a red flag. Use parameterized queries or an ORM.

7. CORS wildcard

Access-Control-Allow-Origin: * means any website can make requests to your API. Combined with missing auth checks, this can expose data to any domain that wants it.

Check: In your browser's DevTools ? Network, look at the response headers for your API calls. If you see access-control-allow-origin: * on authenticated endpoints, investigate.

8. Missing security headers

Security headers protect your users from browser-level attacks: clickjacking (X-Frame-Options), cross-site scripting (Content-Security-Policy), and insecure connections (HSTS). Most vibe-coded apps ship without any of them.

Check: Go to securityheaders.com and enter your URL. A grade below B means you're missing important ones.

What actually happens when these go unfixed

The Quittr story is the clearest example: 600,000 users had their most personal data exposed - confessions, ages, emotional triggers - for the entire lifetime of the app. The founders found out from a journalist, not from a monitoring alert. The app had generated over a million dollars in revenue. The fix was changing five lines of Firebase rules.

The Moltbook breach (January 2026) moved faster: 1.5 million API authentication tokens and 35,000 email addresses exposed within 72 hours of launch. The vector was a Supabase database with no row-level security - the same pattern as CVE-2025-48757.

A Lovable-featured EdTech app (showcased on Lovable's own homepage) was found to have 16 security vulnerabilities, 6 of them critical.

These aren't enterprise targets. They're solo founders and small teams who shipped something that worked and didn't know what they didn't know about security.

How to check your app today

The manual checks above will catch the obvious issues. But some vulnerabilities only show up at the intersection of source code and live site behavior - a secret that's in the code but only exposed after build, or an RLS configuration that looks correct but has a gap in one policy.

VibeSafe runs 16 checks across both layers - source code and live site - using static analysis, secret scanning, live header inspection, and behavior probing. You get a report with plain-English descriptions of each finding and exact steps to fix them.

Pricing is $19-$49 one-time. No subscription.

The Shield: preventing this on your next project

Even if you fix everything today, the next app you build with AI tools will generate the same patterns again - because the models haven't changed.

VibeSafe includes something called The Shield: an AI context file (CLAUDE.md, .cursorrules, or .windsurfrules depending on your tool) that you drop into your project at the start. It instructs your AI assistant to follow secure defaults: no hardcoded secrets, RLS enabled on every table, webhook signature verification, parameterized queries. The model follows the constraint file, so the vulnerable patterns don't get generated in the first place.

Conclusion: scan before you ship

The vulnerabilities in this list aren't hard to introduce - AI tools introduce them by default. And they're not hard to find, once you know what to look for.

The founders who built Quittr weren't careless. They shipped in 10 days using tools that made it easy, and no one told them what the defaults were leaving open. This checklist exists so you don't find out the same way they did.

Scan your app. Fix what you find. Ship with confidence.

VibeSafe runs 16 security checks on vibe-coded apps - source code and live site. Plain-English report, exact fixes, trust badge. One-time pricing from $19. ? vibesafe.store

I Audited 5 AI-Built Apps for Security. All 5 Had Critical Vulnerabilities. Tags: #security #ai #webdev #programming #cybersecurity

kg8888 — Thu, 18 Jun 2026 05:06:49 +0000

AI coding tools are incredible. Cursor, Lovable, Bolt, Replit, v0 — they've made shipping software faster than ever. Non-technical founders can now build full apps in a weekend.

But there's a catch nobody talks about enough:

AI optimizes for code that works, not code that's secure.

When your AI assistant suggests making your storage bucket public, or disabling Row Level Security on your database, or hardcoding an API key — it's not being malicious. It's taking the path of least resistance. And that path leads straight to a breach.

The Numbers Are Scary

Wiz scanned 5,600 AI-built apps: 400 had exposed secrets
GuardMint audited 200+: 91.5% had vulnerabilities directly from AI hallucination
Lovable ships 70% of apps with Row Level Security disabled
Bolt turns RLS off by default

Martin Fowler's team at Thoughtworks put it perfectly:

"Telling an AI agent to be safe is not the same as enforcing that it is safe. Prompts can be overridden, misunderstood, or ignored."

What I Found in 5 Manual Audits

#	Issue	Apps Affected
🔴	Exposed API key or DB password in frontend JS	3/5
🔴	Row Level Security completely disabled	4/5
🔴	Publicly readable database (entire DB)	1/5
🟡	Routes missing auth checks	3/5
🟡	Storage buckets set to public	2/5
🟡	Missing rate limiting on auth endpoints	5/5

Every single founder was shocked. They had no idea any of this was happening.

The 5 Things AI Coding Tools Consistently Get Wrong

1. Hardcoding Secrets

const supabase = createClient(
  'https://abc123.supabase.co',
  'eyJhbGciOi...full-anon-key...'  // 🔴 IN FRONTEND JS!
);

2. Disabling Row Level Security

Supabase's RLS is opt-in. AI tools don't enable it unless you explicitly ask. Result: anyone with your anon key can read every row in every table.

3. Public Storage Buckets

AI: "Let's make this bucket public so images load faster."
Reality: every file in that bucket is now accessible to anyone with a URL.

4. Over-Permissioned Service Accounts

AI tools often create service accounts with admin or owner roles because it's the simplest way to make things work.

5. Missing Auth Guards

app.get('/api/user-data', (req, res) => {
  // No auth check! Anyone can hit this.
  const data = await db.query('SELECT * FROM users');
  res.json(data);
});

The Fix: Two Things Every Vibe Coder Needs

1. An Audit (Check What's Broken)

Run a security scan on your codebase. Look for exposed secrets, database permissions, auth gaps, dependency vulns, security headers.

2. A Shield (Prevent Future Mistakes)

Add a .cursorrules or CLAUDE.md that tells your AI:

Never hardcode secrets
Always enable RLS
Never make storage buckets public
Always use least-privilege service accounts
Always add auth checks to protected routes

I Built This

I built VibeSafe to automate both:

Pre-Launch Audit ($39) — Scan your GitHub repo. Plain-English report in 24 hours.
Post-Launch Scan ($19) — Scan your live URL. SSL, headers, exposed files. Trust badge included.
Shield ($29) — Auto-generated security context file for your exact stack.
Full Bundle ($49) — All three.
Continuous ($39/mo) — Weekly rescans + breach monitoring.

Built for founders, not security engineers. If you can ship an app with AI, you can use this.

Quick check for your own codebase:

grep -r "eyJ" --include="*.js" --include="*.ts" --include="*.tsx" .
grep -r "api_key\|apikey\|secret\|password\|token" --include="*.js" .

You might be surprised what you find.