What are Vercel security best practices?

The best practices specific to Vercel (not generic OWASP)

Every "security best practices" list tells you to use HTTPS and rotate keys. Those are table stakes. The list below is what actually matters for Vercel apps, based on the risks that appear in real Vercel deployments.

1. Audit variable scopes in Vercel dashboard

*Why:* Secrets in wrong scope (Development vs Preview vs Production). *Do this:* Audit variable scopes in Vercel dashboard. Use correct environment targeting.

2. Enable Vercel Authentication for preview deployments

*Why:* Preview URLs expose unreleased features without authentication. *Do this:* Enable Vercel Authentication for preview deployments.

3. Configure headers in next

*Why:* Deployed sites without CSP, HSTS, or frame protection. *Do this:* Configure headers in next.config.js or vercel.json.

4. Remove debug logging

*Why:* Secrets accidentally logged in function console output. *Do this:* Remove debug logging. Never console.log sensitive data.

5. Verify auth in all edge functions

*Why:* Edge functions with improper auth or CORS configuration. *Do this:* Verify auth in all edge functions. Configure CORS strictly.

Vercel-specific: audit every table for RLS before every deploy

The failure mode in Vercel + Supabase apps is always the same: a table gets added during a feature push, RLS never gets turned on, the full table becomes queryable via the anon key. Bake a pre-deploy check: `select tablename from pg_tables where schemaname = 'public' and not rowsecurity` — the result must be empty.

Verification

Even perfect best practices don't prove themselves — the only way to confirm the list above is implemented is to scan a deployed Vercel app. VAS probes each of env variable security, serverless security, headers config, auth protection by actually attempting the attack, not just reading headers or docs.