Anthropic Just Dropped Mythos, And It Can Hack Big Tech. Here's How to Stay Safe While Vibecoding.

Claude Mythos just found thousands of zero-day vulnerabilities across every major operating system and browser. Bugs that have been sitting there for 27 years. Anthropic won't even release it publicly because it's too good at hacking.

That's the frontier. But here's the ground-level reality that should worry you just as much:

Thousands of developers are vibecoding apps right now with zero security awareness. Shipping SaaS tools with API keys in the frontend. No auth on endpoints. No input validation. Nothing.

I had a conversation with a guy last week. Someone contacted him about his AI-powered SaaS tool. They'd found all of his API keys exposed. Billing keys. Database keys. Everything. And it was legit.

This guide exists because the barrier to building dropped, but the knowledge to build safely didn't come with it.

What is Vibecoding (and Why It's a Security Problem)

Vibecoding is when you build software primarily through AI - prompting Claude, Cursor, Copilot, or similar tools to write most of the code. You describe what you want, the AI builds it, you ship it.

The problem: AI optimizes for working code, not secure code. It gives you something functional as fast as possible. Security is an afterthought - if it's a thought at all.

When you don't fully understand what the AI generated, you can't spot the holes. And the holes are everywhere.

Mistake 1: API Keys in the Frontend

This is the most common and most catastrophic. Your AI tool happily puts API keys right in the client-side code because you asked it to "connect to the API."

Anyone who opens browser DevTools can see them. Every key. Billing, database, third-party services - all exposed.

The Fix

• Never put API keys in frontend code. Full stop.
• Use environment variables on the server side (.env files, never committed to git)
• Create API routes (Next.js /api/, Express endpoints) that call external services from the server
• Use .gitignore to exclude .env files from your repo

# .gitignore - these should ALWAYS be here
.env
.env.local
.env.production
*.pem

Mistake 2: No Authentication on API Endpoints

Your AI builds a beautiful API. It returns data, creates records, processes payments. And it's completely open. No auth check. Anyone with the URL can call it.

This happens because AI writes endpoints that work - meaning they do what you asked. It doesn't add auth unless you specifically ask for it.

The Fix

• Add authentication middleware to ALL non-public endpoints
• Use established auth libraries (NextAuth, Clerk, Supabase Auth) - don't roll your own
• Check permissions on every request, not just at the route level
• Test by calling your endpoints without auth tokens - if they return data, you have a problem

Mistake 3: No Input Validation

Your AI builds a form. User enters data. Data goes to the database. No validation. No sanitization.

This opens you to:

• SQL injection - attacker writes database commands in form fields
• XSS (Cross-Site Scripting) - attacker injects JavaScript that runs on other users' browsers
• Data corruption - wrong types, missing fields, broken references

The Fix

• Validate ALL user input on the server side (client-side validation is for UX, not security)
• Use a validation library like Zod (TypeScript) or Pydantic (Python)
• Sanitize HTML output to prevent XSS
• Use parameterized queries or an ORM - never build SQL strings with user input

// Bad - AI might generate this
const user = await db.query(\`SELECT * FROM users WHERE id = \${req.params.id}\`);

// Good - parameterized
const user = await db.query('SELECT * FROM users WHERE id = $1', [req.params.id]);

Mistake 4: Overly Permissive Database Rules

Firebase, Supabase, and other BaaS platforms have security rules. AI often sets them to completely open during development:

{
  "rules": {
    ".read": true,
    ".write": true
  }
}

This means anyone can read and write anything in your entire database. And people ship this to production.

The Fix

• Write specific rules for each table/collection
• Users should only access their own data
• Admin operations should require admin roles
• Test your rules by trying to access other users' data

Mistake 5: No Rate Limiting

Your API has no rate limiting. Someone writes a script that hits your endpoint 10,000 times per second. Your server crashes, your database overloads, your billing spikes.

Or worse: they brute-force your login endpoint.

The Fix

• Add rate limiting to all public endpoints (especially auth endpoints)
• Use libraries like express-rate-limit or Vercel's built-in rate limiting
• Set strict limits on login attempts (5-10 per minute max)
• Add rate limiting to any endpoint that costs you money (AI API calls, email sending)

Mistake 6: CORS Wide Open

AI often sets CORS to allow everything:

// AI-generated - allows any website to call your API
cors({ origin: '*' })

This means any website can make requests to your API on behalf of your users. That includes malicious sites.

The Fix

• Set CORS to only allow your own domain(s)
• Be explicit about allowed methods and headers
• Never use origin: '*' in production

cors({
  origin: ['https://yourdomain.com'],
  methods: ['GET', 'POST'],
  credentials: true,
})

Mistake 7: No HTTPS / Insecure Cookies

Some vibecoded projects serve over HTTP or set cookies without security flags. This means credentials can be intercepted on public WiFi networks.

The Fix

• Always use HTTPS in production (most hosting platforms do this automatically)
• Set cookie flags: Secure, HttpOnly, SameSite=Strict
• Use Secure flag so cookies only transmit over HTTPS
• Use HttpOnly so JavaScript can't access auth cookies (prevents XSS cookie theft)

Mistake 8: Exposing Error Details

AI-generated error handling often returns full stack traces and internal error details to the client:

// Bad - tells attackers exactly how your app works
catch (error) {
  res.status(500).json({ error: error.message, stack: error.stack });
}

This gives attackers a roadmap of your codebase.

The Fix

• Return generic error messages to clients ("Something went wrong")
• Log detailed errors server-side only
• Never expose database schemas, file paths, or stack traces in API responses
• Use different error detail levels for development vs production

Mistake 9: Not Keeping Dependencies Updated

Your vibecoded project uses 50+ npm packages. AI installed whatever version was current when it generated the code. Six months later, 12 of those packages have known vulnerabilities.

The Fix

• Run npm audit regularly (or pnpm audit)
• Set up automated dependency updates (Dependabot, Renovate)
• Don't ignore security warnings during install
• Pin major versions but allow patch updates

The Security Checklist

Before you ship anything vibecoded to production, run through this:

1. 1API keys - Are they all server-side? None in frontend code or git history?
2. 2Authentication - Does every non-public endpoint check auth?
3. 3Input validation - Is all user input validated server-side?
4. 4Database rules - Are they locked down to user-specific access?
5. 5Rate limiting - Are public endpoints rate-limited?
6. 6CORS - Is it restricted to your domains only?
7. 7HTTPS + cookies - Secure flags set? HTTPS enforced?
8. 8Error handling - No stack traces or internal details exposed?
9. 9Dependencies - Recently audited? Auto-updates enabled?

Why This Matters More Than Ever

Claude Mythos found bugs in the most secure systems on earth - operating systems maintained by billion-dollar companies with dedicated security teams.

If AI can find holes in OpenBSD, FreeBSD, and every major browser - imagine what it can find in a SaaS tool that was vibecoded in a weekend with no security review.

The tools to build are getting better every month. The tools to break in are getting better just as fast.

The developers who survive this era are the ones who treat security as step one, not step last.