30 security rules for vibe coders

Category 01

Authentication & sessions

Rules 1–2

Set session expiration (JWT max 7 days + refresh rotation)

Long-lived tokens are a liability. If one is stolen, the attacker has access indefinitely. Refresh rotation issues a new token on every use, so a stolen token becomes invalid quickly — the next legitimate request replaces it.

Never use AI-built auth. Use Clerk, Supabase Auth, or Auth0

Auth is the most security-critical part of your app and the hardest to get right. Purpose-built providers handle the edge cases AI-generated code misses: token revocation, MFA, brute force protection, session fixation, and PKCE flows.

Category 02

Secrets & keys

Rules 3–5

Never paste API keys into AI chats. Use process.env

Chat sessions are logged and may be used for training. Even "private" conversations can be accessed. Reference environment variables in your code — share the code, not the values.

.gitignore is your first file in every project, not the last

A secret committed to git lives in the history forever — even if you delete the file. Bots scan public repos continuously and will find it within minutes. Create .gitignore before your first commit, not after you realize what you pushed.

Rotate secrets every 90 days minimum

Keys that never change are more likely to be compromised without your knowing. Regular rotation limits the window of exposure for any leaked credential. Most providers let you pre-create a replacement before revoking the old one.

Category 03

Dependencies

Rules 6–8

Verify every package the AI suggests actually exists before installing

AI models hallucinate package names. Attackers create packages with plausible names (typosquatting) that execute malicious code on install. Check npmjs.com or PyPI directly before running any install command.

Always ask for newer, more secure package versions

Older versions often have known vulnerabilities with public exploits. AI assistants sometimes suggest versions from their training data, which may be outdated. Explicitly ask for current versions, or check the package registry.

Run npm audit fix right after building

Dependency vulnerabilities accumulate silently as upstream packages receive patches. Run this every build to catch known CVEs before they reach production. For severe issues npm audit fix --force handles them aggressively (check for breaking changes).

Category 04

Input & database security

Rules 9–10

Sanitize every input. Use parameterized queries always

SQL injection is one of the most exploited vulnerabilities in existence. Never concatenate user input into SQL strings. Parameterized queries (also called prepared statements) separate code from data at the driver level — the database never interprets user input as SQL.

Enable Row-Level Security from day one

Without RLS, a single misconfigured query can return another user's data. In Supabase and PostgreSQL, RLS enforces access policies at the database level — not just the application layer. If your app code has a bug, the database still holds the line.

Category 05

Network & code hygiene

Rules 11–13

Remove all console.log statements before shipping

Logs can expose user data, API keys, internal state, and system paths to anyone with DevTools open. They also slow down production apps. Use a proper logging library that can be disabled by environment rather than deleting statements manually each time.

CORS should only allow your production domain. Never wildcard

A wildcard CORS policy (*) lets any website make authenticated requests to your API on behalf of your users. Lock it to your exact production domain — and add localhost only in development, never in production builds.

Validate all redirect URLs against an allow-list

Open redirects let attackers create convincing phishing links using your domain: yourapp.com?redirect=evil.com. If your app redirects based on a URL parameter, only allow a hardcoded set of known-safe destinations.

Category 06

Rate limiting

Rules 14–16

Apply auth + rate limits to every endpoint, including mobile APIs

Mobile apps often talk to separate API endpoints that developers forget to protect. Unauthenticated or unlimited mobile endpoints are a common attack vector because they look like "internal" infrastructure but are just as exposed as your web API.

Rate limit everything from day one. 100 req/hour per IP is a start

Without rate limits, a single bad actor can hammer your API, rack up your costs, or brute-force credentials. Retrofitting rate limits onto a production system is painful. Add them at the start with a library like express-rate-limit or at the edge via Cloudflare.

Password reset routes get their own strict limit (3 per email/hour)

Password reset endpoints are prime targets for account enumeration (figuring out which emails are registered) and spam attacks. A limit stricter than your general rate limit protects both user security and your email sender reputation.

Category 07

Infrastructure & costs

Rules 17–18

Cap AI API costs in your dashboard AND in your code

A prompt injection attack or runaway usage spike can generate massive bills overnight. Set hard limits in your provider's billing dashboard and add code-level guards (token counting, per-user quotas) to catch abuse before it reaches the billing ceiling.

Add DDoS protection via Cloudflare or Vercel edge config

Volumetric attacks can take your app offline in seconds. Edge-level protection absorbs traffic before it reaches your servers. Cloudflare's free plan is sufficient for most small apps — enable it before you launch, not after your first outage.

Category 08

Storage, uploads & payments

Rules 19–22

Lock down storage buckets. Users should only access their own files

Public or misconfigured buckets are one of the most common cloud security mistakes — responsible for major data breaches at companies of all sizes. Every file access should be scoped to the authenticated user who owns it, enforced by bucket policies or signed URLs.

Limit upload sizes and validate file type by signature, not extension

Attackers rename malicious files to bypass extension checks. Read the actual file header bytes to determine type (e.g., file-type in Node.js). Also cap file sizes — unlimited uploads are storage abuse waiting to happen.

Verify webhook signatures before processing any payment data

Anyone can send a POST request to your webhook endpoint. Stripe, Paddle, and other payment providers sign their payloads with a secret key. Always verify the signature before processing — or attackers can fake payment events and trigger fulfillment without paying.

Use Resend or SendGrid with proper SPF/DKIM records

Without SPF/DKIM, your emails land in spam or get blocked entirely. Worse, your domain can be spoofed. Purpose-built email providers handle authentication record setup. Verify deliverability with mail-tester.com before launch.

Category 09

Authorization & AI-assisted review

Rules 23–25

Check permissions server-side. UI-level checks are not security

Hiding a button in the UI doesn't restrict access to the underlying API. Users can call your endpoints directly with curl or browser DevTools. All access control must be enforced on the server — the UI is just a convenience layer.

Ask the AI to act as a security engineer and review your code

Prompt: "Review this code for security vulnerabilities — act as a senior security engineer." This mode surfaces SQL injection, exposed secrets, and auth bypasses that normal coding assistance doesn't flag. The framing matters.

Ask the AI to try and hack your app. It will find things you won't

Prompt: "Here is my authentication flow. Find ways to exploit it." Adversarial prompting surfaces edge cases and attack paths that standard code review misses — race conditions, token leakage, privilege escalation paths.

Category 10

Operations & compliance

Rules 26–30

Log critical actions: deletions, role changes, payments, exports

An audit trail is how you investigate incidents, comply with regulations, and detect abuse. If you can't answer "who deleted this?" or "when did this role change?", you're missing the logs you'll need when something goes wrong — and something will.

Build a real account deletion flow. GDPR fines are not fun

GDPR Article 17 gives users the right to erasure. A "delete account" button that hides the user record is not compliant. You need to actually purge or anonymize all their personal data — including backups and third-party systems you've shared data with.

Automate backups and test restoration. An untested backup is nothing

Backups you've never restored may be corrupt, incomplete, or in the wrong format. Run a restoration drill on a schedule — before you need it. The worst time to discover your backup process is broken is during an incident.

Keep test and production environments completely separate

Shared credentials, databases, or infrastructure between environments means a test mistake can damage production data. Use completely separate accounts, API keys, and configs. An NODE_ENV check is not the same as separate infrastructure.

Never let test webhooks touch real systems

A Stripe test event hitting your production webhook handler can trigger real fulfillment logic, send real emails, or corrupt real records. Use completely separate webhook endpoints per environment, or add a strict environment check at the top of every handler.

Your progress

Get started

Check off rules as you apply them to your project. Progress is saved in your browser so you can pick up where you left off. Critical rules (marked in red) should be addressed first.

Critical rules — do these first

01 — Set session expiration with refresh rotation

02 — Never use AI-built auth

03 — No API keys in AI chats

04 — .gitignore before first commit

09 — Parameterized queries always

10 — Row-Level Security from day one

12 — No wildcard CORS

19 — Lock down storage buckets

21 — Verify webhook signatures

23 — Server-side permission checks

28 — Test your backup restoration

29 — Separate test and prod environments

30 — Test webhooks stay in test systems