Security checklist for vibe coders before pushing to production

Before you push, check these things

Vibe coding is fast. Genuinely fast. You describe what you want, the model builds it, you glance at the output, it looks right, and you ship. That loop is intoxicating, and I get why people love it.

The problem is that security doesn't announce itself. A hardcoded API key doesn't throw an error. A missing rate limit doesn't cause a test failure. An open S3 bucket doesn't print a warning to the console. These things sit quietly in your codebase until someone else finds them, and that someone else is usually not friendly.

Here is a practical checklist you can run through before every production push. It's not exhaustive, but it covers the categories where vibe-coded projects most often fall down.

---

1. Scan for committed secrets

The single most common mistake. A key goes in as a quick test, the test works, the file gets committed, and now your OpenAI key is in GitHub's index forever.

Before pushing, run:

git log --all -p | grep -iE "(api_key|secret|password|token)\s*=\s*['"][^'"]{8,}"

That's a rough grep, not a complete solution. For anything serious, use a dedicated tool:

npx trufflesecurity/trufflehog git file://. --only-verified

If you find a leaked secret: rotate it immediately, then worry about cleaning history. The other order gets people into trouble.

2. Check your dependencies for known CVEs

AI-generated dependency lists are not curated. The model picks whatever version it knows about from training data, which may be months or years out of date. Known vulnerabilities accumulate fast.

npm audit

For anything flagged as high or critical, upgrade or replace before shipping. npm audit fix handles most of it automatically. Where it can't, you need to decide whether the vulnerability is actually reachable in your code.

3. Look for hardcoded configuration

Secrets are the obvious case, but there's a broader class of hardcoded values that cause production pain: hardcoded environment names (if (env === "production")), hardcoded URLs pointing to local services, hardcoded port numbers that conflict with whatever's running in prod.

Check your environment variable usage:

grep -rn "localhost" src/ --include="*.ts" --include="*.js"
grep -rn "127\.0\.0\.1" src/ --include="*.ts" --include="*.js"

If you're hitting localhost in code that runs in production, that's a bug waiting to happen.

4. Verify error handling doesn't leak internals

AI models tend to write overly helpful error messages. Stack traces, database query strings, internal file paths: all of these show up in AI-generated catch blocks because they make debugging easier during development. They also make exploiting your app easier.

Search for patterns like:

grep -rn "err.stack\|error.message\|console.error(err" src/ --include="*.ts"

Any place where raw error objects get sent to API responses or rendered in the browser is a problem. Log internally, return a generic message externally.

5. Check that authentication is actually wired up

This one stings. AI-generated route handlers often include an auth middleware import at the top of the file but then forget to attach it to every route. Or they protect the POST routes but leave GET routes open because "they're read-only anyway."

Read every route file. Confirm that middleware is applied where you expect it. If you're using Express, check that the middleware is registered before the routes that need it, not after.

6. Validate that rate limiting exists on sensitive endpoints

Login endpoints, password reset flows, contact forms, and any endpoint that triggers an email or SMS: all of these need rate limiting. Without it, you're one bored person away from a spam flood or a credential stuffing attack.

Check that your rate limiting library is actually imported and called, not just listed as a dependency.

7. Review what's exposed in your API responses

AI models build API responses that include all fields from a database model by default. That often means returning password hashes, internal IDs, soft-delete flags, or user metadata that clients have no business seeing.

For every API response that returns user data, ask: should this field be here? The answer for password_hash is always no. The answer for internal_notes is probably no. Write an explicit allowlist of fields for each response type rather than returning the raw model.

8. Confirm HTTPS is enforced end to end

Your hosting platform probably handles TLS, but check that HTTP requests get redirected to HTTPS, not silently served over plaintext. Also check that cookies have the Secure and HttpOnly flags set.

9. Check Content Security Policy headers

Missing CSP headers are the kind of thing that takes thirty seconds to add and gets skipped 100% of the time when you're moving fast. A basic CSP catches entire classes of injection attacks.

If you're on Next.js:

// next.config.js
const securityHeaders = [
  { key: 'Content-Security-Policy', value: "default-src 'self'" },
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
];

Not perfect, but dramatically better than nothing.

10. Run a static analysis pass before every push

Honestly, the checks above are things a tool should do for you. Reading your own code for security issues is error-prone, especially after a long session of AI-assisted building where you've been trusting the output rather than auditing it.

Make the scan part of your commit workflow. The ten minutes it takes to set up pays back immediately the first time it catches something.

---

None of this is glamorous. It doesn't feel like building. But the alternative is the 2am incident where you're rotating credentials and wondering how long the breach has been going on.

Seaworthy is a static analysis tool that automates most of these checks, scanning for hardcoded secrets, missing rate limiting, exposed error details, and a range of other issues across security, ops, and resilience categories.