I'm a bug bounty hunter and pentester. I've spent the last 5 years chasing security vulnerabilities in web apps, from small local companies to Google and Reddit.
When vibe-coding took off, social media got flooded with memes about insecure vibe-coded apps. And honestly? They're not wrong.
There are 2 reasons for this:
- Most vibe coders don't have a dev background - so they're not aware of security risks in the first place
- LLMs produce vulnerable code by default - doesn't matter which model, they all make the same mistakes unless you explicitly guide them
From a bug hunter's perspective, security is about finding exceptions; the edge cases developers forgot to handle.
I've seen so many of them:
- A payment bypass because the price was validated client-side
- Full account takeover through a password reset that didn't verify email ownership
- Admin access by changing a single parameter in the request
If senior developers at Google make these mistakes, LLMs will definitely make them too.
So here's how you can secure your vibe-coded apps without being a security expert:
1. Securing the Code
The best approach is to prevent vulnerabilities from being written in the first place. But you can't check every line of code an LLM generates.
I got tired of fixing the same security bugs over and over, so I created a Skill that forces the model to adopt a Bug Hunter persona from the start.
It catches about 70% of common vulnerabilities before I even review the code, specifically:
- Secret Leakage (e.g., hardcoded API keys in frontend bundles)
- Access Control (IDOR, privilege escalation nuances)
- XSS/CSRF
- API issues
It basically makes the model think like an attacker while it builds your app.
You can grab the skill file here (it's open source):
https://github.com/BehiSecc/VibeSec-Skill
2. Securing the Infrastructure
Not every security issue happens in the code.
You can write perfect code and still get hacked because of how you deployed or configured things.
Here are 8 common infrastructure mistakes to avoid:
-
Pushing secrets to public GitHub repos - use
.gitignoreand environment variables, never commit.envfiles - Using default database credentials - always change default passwords for Postgres, MySQL, Redis, etc.
- Exposing your database to the internet - your DB should only be accessible from your app server, not the public internet
- Missing or broken Supabase RLS policies - enable RLS policy
- Debug mode in production - frameworks like Django/Flask/Laravel show stack traces, and secrets when debug is on
- No backup strategy - if your database gets wiped (or encrypted by ransomware), can you recover?
- Running as root - your app should run as a non-privileged user, not root
-
Outdated dependencies - run
npm auditorpip auditregularly, old packages might have known exploits
Quick Checklist Before You Launch
- No API keys or secrets in your frontend code
- All API routes verify authentication server-side
- Users can only access their own data (test with 2 accounts)
- Your dependencies are up to date
- .env files are in
.gitignore - Database isn't exposed to the internet
- Debug mode is OFF in production
If you want the AI to handle most of this automatically while you code, grab the skill. If you prefer doing it manually, this post should give you a solid starting point.
Happy to answer any security questions in the comments.
Top comments (2)
As someone who relies on AI coding tools daily, this is the perspective I needed. The pattern I've started using is treating AI-generated security-sensitive code the same way I treat third-party libraries — assumed untrusted until reviewed. For auth flows, payment logic, and anything touching user data, I won't ship AI-generated code without a dedicated security review pass, regardless of how clean the output looks. I've also started adding explicit security constraints to my project context files: 'never use eval(), always use parameterized queries, never log sensitive fields.' Doesn't catch everything but dramatically reduces the worst patterns.
Agreed. The skill already covers many of those edge cases, so you don't really need to write your own rules.