I kept seeing the same pattern when I check vibe coded site (what I do every day) founders ship apps built with Cursor, Lovable or Bolt, get their first users, celebrate and have exposed API keys, broken auth, and injectable endpoints sitting in production... I have found at least 30+ API key... I like shipping fast but I don't like that kind of behavious with security.
The LLMs are great at making things work. Indeed they're not optimized for making things safe. And most vibe coders don't have a security background, so they don't know what to look for.
So I built a scanner (before Claude does it) specifically for this: you drop your URL, it runs a set of checks, and returns a prioritized list of vulnerabilities with severity levels. The idea is to make it actionable not just "you have a problem" but "here's the exact prompt to fix it in Cursor/lovable."
Free to scan. First vulnerability shown for free, full report behind a paywall.
What's your current approach to security when you vibe code something and push it live? Tbh I am really curious if this is a problem people are actually solving or just ignoring.
Honestly I see this all the time too. People are super excited to ship fast, get their first users, post the launch… and meanwhile their keys are sitting in the frontend or the auth logic is basically optional
I think the problem isn’t that founders don’t care, it’s more that when you’re vibe coding you’re focused on “does it work?” not “is it safe?”. And since the LLM makes everything feel easy, you don’t always realize what you just exposed to the internet.
My current approach is pretty simple: I assume everything I ship is public and hostile by default. So I try to move secrets server-side, use environment variables properly, add basic rate limiting, and at least test endpoints manually before pushing. It’s not perfect, but it prevents the obvious disasters.
Your scanner idea actually makes a lot of sense, especially if it gives concrete fixes instead of just scary warnings. Most builders won’t read a security report, but they will paste a prompt into Cursor to fix the issue.
Curious to see how people react to it, because right now it really feels like security is the thing everyone knows matters… but postpones until something breaks.
I kept seeing the same pattern when I check vibe coded site (what I do every day) founders ship apps built with Cursor, Lovable or Bolt, get their first users, celebrate and have exposed API keys, broken auth, and injectable endpoints sitting in production... I have found at least 30+ API key... I like shipping fast but I don't like that kind of behavious with security.
The LLMs are great at making things work. Indeed they're not optimized for making things safe. And most vibe coders don't have a security background, so they don't know what to look for.
So I built a scanner (before Claude does it) specifically for this: you drop your URL, it runs a set of checks, and returns a prioritized list of vulnerabilities with severity levels. The idea is to make it actionable not just "you have a problem" but "here's the exact prompt to fix it in Cursor/lovable."
Free to scan. First vulnerability shown for free, full report behind a paywall.
What's your current approach to security when you vibe code something and push it live? Tbh I am really curious if this is a problem people are actually solving or just ignoring.
Honestly I see this all the time too. People are super excited to ship fast, get their first users, post the launch… and meanwhile their keys are sitting in the frontend or the auth logic is basically optional I think the problem isn’t that founders don’t care, it’s more that when you’re vibe coding you’re focused on “does it work?” not “is it safe?”. And since the LLM makes everything feel easy, you don’t always realize what you just exposed to the internet.
My current approach is pretty simple: I assume everything I ship is public and hostile by default. So I try to move secrets server-side, use environment variables properly, add basic rate limiting, and at least test endpoints manually before pushing. It’s not perfect, but it prevents the obvious disasters.
Your scanner idea actually makes a lot of sense, especially if it gives concrete fixes instead of just scary warnings. Most builders won’t read a security report, but they will paste a prompt into Cursor to fix the issue.
Curious to see how people react to it, because right now it really feels like security is the thing everyone knows matters… but postpones until something breaks.