The vibe-coding security checklist

Run this against your Postgres database and read the qual column for every table holding user or business data:

select schemaname, tablename, policyname, qual
from pg_policies
where tablename = 'orders';

If a sensitive table has no rows at all, RLS was likely never enabled. If a policy exists but qual reads true, it's "enabled" in name only, it allows everyone.

The classic broken pattern, looks protected, isn't:

alter table orders enable row level security;

create policy "orders_select" on orders
  for select
  using (true);  -- true means "always allowed", to everyone

The actual fix, scoped to the record's real owner:

alter table orders enable row level security;

create policy "orders_select_own" on orders
  for select using (auth.uid() = user_id);

create policy "orders_insert_own" on orders
  for insert with check (auth.uid() = user_id);

create policy "orders_update_own" on orders
  for update using (auth.uid() = user_id)
  with check (auth.uid() = user_id);

Confirm two things separately: first, that only the anon/public key appears in your client-side code (search for service_role in your frontend, it should return zero results). Second, verify item 01 above, because the anon key's safety is entirely conditional on RLS being correct.

Never ship the service_role key, which bypasses RLS entirely, to any client-side code. It belongs only in server-side environment variables, used only in backend functions that themselves enforce their own authorization:

// server-only, never in a client bundle
const supabaseAdmin = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_SERVICE_ROLE_KEY // no NEXT_PUBLIC_ / VITE_ prefix
);

Build your app for production, then grep the actual built output, not your source files:

grep -rE "sk_live_|sk_test_|service_role|AIza[0-9A-Za-z_-]{35}" ./dist ./build ./.next 2>/dev/null

Also check that any environment variable holding a secret does not use a client-exposed prefix. Any variable named NEXT_PUBLIC_*, VITE_*, or REACT_APP_* gets bundled into client-visible JavaScript by design, that prefix is a promise to your bundler that the value is public.

If a grep above finds a live key, rotate it immediately, in this order: generate a new key in the provider's dashboard (Stripe: Developers → API keys → roll key; OpenAI: API keys → revoke and create), update your server-only environment variable, deploy, then revoke the old key last so nothing breaks mid-rotation. Move the call itself server-side:

// client calls your own server, never the third-party API directly
const res = await fetch('/api/create-payment-intent', { method: 'POST', body: ... });

// your server, holding the real secret key
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY); // server-only env var

Log in as user A, note the URL or ID for one of their records (an invoice, an order), then, still logged in as user A, request user B's record by ID directly. If it returns data, that's an IDOR (insecure direct object reference).

Vulnerable, checks login but not ownership:

app.get('/api/invoices/:id', requireAuth, async (req, res) => {
  const invoice = await db.invoice.findUnique({ where: { id: req.params.id } });
  res.json(invoice);
});

Fixed, ownership is part of the query itself, not a separate check that can be forgotten:

app.get('/api/invoices/:id', requireAuth, async (req, res) => {
  const invoice = await db.invoice.findFirst({
    where: { id: req.params.id, userId: req.user.id }
  });
  if (!invoice) return res.status(404).json({ error: 'not found' });
  res.json(invoice);
});

Pick any endpoint that writes data and send it a request with an unexpected type, a negative number, or an extra field using curl or Postman. If your server accepts it without complaint, there's no validation.

Validate every request against an explicit schema before touching it:

import { z } from 'zod';

const CreateOrderSchema = z.object({
  productId: z.string().uuid(),
  quantity: z.number().int().positive().max(50),
  shippingAddress: z.object({
    line1: z.string().min(1).max(200),
    zip: z.string().regex(/^\d{5}(-\d{4})?$/)
  })
});

const parsed = CreateOrderSchema.safeParse(req.body);
if (!parsed.success) return res.status(400).json({ error: parsed.error.flatten() });

Search your codebase for any raw query built with string concatenation or template literals containing a variable:

grep -rn "SELECT.*\${" --include="*.js" --include="*.ts" .

Vulnerable:

db.query(`SELECT * FROM users WHERE email = '${email}'`);

Fixed, parameterized so user input is always treated as data, never as code:

db.query('SELECT * FROM users WHERE email = $1', [email]);

Any ORM (Prisma, Drizzle, Sequelize) parameterizes automatically when you use its query builder correctly, the risk is almost always in a hand-written "raw" escape hatch.

Search for the escape hatches that bypass a framework's automatic escaping:

grep -rn "dangerouslySetInnerHTML\|v-html" --include="*.jsx" --include="*.tsx" --include="*.vue" .

If you must render user-generated HTML (a rich text editor, a comment with formatting), sanitize it first:

import DOMPurify from 'dompurify';

<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userContent) }} />

If the content is plain text, don't use the raw-HTML escape hatch at all, render it as text and let the framework escape it automatically.

Look at your CORS config for the combination of a wildcard origin and credentials enabled, that pairing should never appear together.

Vulnerable:

app.use(cors({ origin: '*', credentials: true })); // never combine these two

Fixed, an explicit allowlist of your real frontend domains:

app.use(cors({ origin: ['https://app.yourdomain.com'], credentials: true }));

Send 50 rapid requests to your login endpoint or any AI/SMS-calling endpoint from a script. If none are rejected or slowed, there's no limiting in place.

import rateLimit from 'express-rate-limit';

app.use('/api/login', rateLimit({ windowMs: 60_000, max: 5 }));
app.use('/api/', rateLimit({ windowMs: 60_000, max: 60 }));

If you're on a serverless or edge platform, use its native rate limiting (Cloudflare, Vercel) or a hosted service like Upstash's rate limiter, which works across cold starts where in-memory limiting like the above does not.

Try uploading a renamed file (a .php or .exe file renamed to .jpg) through your upload form. If it's accepted, the check is trusting the filename or the client-declared content type, not the actual file.

const allowed = ['image/png', 'image/jpeg', 'application/pdf'];
if (!allowed.includes(file.mimetype) || file.size > 10 * 1024 * 1024) {
  return res.status(400).json({ error: 'invalid file' });
}
// verify actual file content matches its claimed type (magic bytes),
// store outside the webroot or in object storage behind a signed URL,
// never execute or serve uploaded files with the original filename

Send a raw POST request to your webhook URL with a fabricated payload, no signature header. If it's processed, verification is missing.

const sig = req.headers['stripe-signature'];
let event;
try {
  event = stripe.webhooks.constructEvent(req.rawBody, sig, process.env.STRIPE_WEBHOOK_SECRET);
} catch (err) {
  return res.status(400).send('Webhook signature verification failed');
}
// only trust `event` from here on, never the raw parsed body

This pattern applies the same way to any provider's webhooks (Shopify, Twilio, GitHub), each has its own signature header and secret, but the shape of the fix is identical.

npm audit --production
npx osv-scanner --lockfile package-lock.json

Run npm audit fix for non-breaking patches, and manually review and upgrade anything flagged as high or critical that requires a major version bump. Add the scan to your CI pipeline so new vulnerable dependencies get caught before merge, not months later.

Search your logging calls for anywhere the full request object or body is passed in directly, rather than specific, named fields.

// leaks whatever the client sent, including card fields, passwords
logger.info('order created', req.body);

// logs only what you actually need to debug
logger.info('order created', { orderId: order.id, userId: order.userId });

Ask when your last successful restore drill happened. If the honest answer is "never," that's the finding.

Quarterly, restore your latest backup into a separate staging database and verify it, not just that the restore command succeeded, but that row counts and a few known records match what you expect:

pg_restore -d staging_db latest_backup.dump
psql -d staging_db -c "select count(*) from orders;"