Execute apply Vercel security best practices for secrets and access control.
Use when securing API keys, implementing least privilege access,
or auditing Vercel security configuration.
Trigger with phrases like "vercel security", "vercel secrets",
"secure vercel", "vercel API key security".
Secure Vercel deployments with proper secret management, security headers, deployment protection, and access token hygiene. Covers environment variable scoping, Content Security Policy, and preventing common secret exposure patterns.
Prerequisites
Vercel CLI installed and authenticated
Access to Vercel dashboard
Understanding of HTTP security headers
Instructions
Step 1: Secret Management with Environment Variables
# Add secrets scoped to specific environments
vercel env add DATABASE_URL production
vercel env add DATABASE_URL preview
vercel env add DATABASE_URL development
# Use 'sensitive' type — values hidden in dashboard and logs
vercel env add API_SECRET production --sensitive
# Via REST API
curl -X POST "https://api.vercel.com/v9/projects/my-app/env" \
-H "Authorization: Bearer $VERCEL_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"key": "API_SECRET",
"value": "sk-secret-value",
"type": "sensitive",
"target": ["production"]
}'
Critical rule: Never prefix secrets with NEXT_PUBLIC_. Variables starting with NEXT_PUBLIC_ are inlined into the client JavaScript bundle and visible to anyone.
vercel-authentication — requires Vercel team login to view preview deploys
standard-protection — uses bypass header for automation
Deployment Protection Bypass — for CI/CD and health checks:
# Generate a bypass secret in Vercel dashboard > Settings > Deployment Protection
# Use in CI with:
curl -H "x-vercel-protection-bypass: your-bypass-secret" \
https://my-app-preview.vercel.app/api/health
Step 5: Access Token Best Practices
# Create scoped tokens — restrict to one team and project
# Settings > Tokens > Create Token:
# - Scope: Team → your-team
# - Expiration: 90 days (for CI)
# - Permissions: Deployment-only (no team admin)
# Rotate tokens on a schedule
# In CI (GitHub Actions):
# Store as GitHub Secret: VERCEL_TOKEN
# Set expiry alerts in your calendar
Token security rules:
Never commit tokens to git — use .env.local or CI secrets
Scope tokens to the minimum required permissions
Set expiration dates (90 days for CI, 30 days for dev)
Rotate immediately if exposed
Use separate tokens per environment/pipeline
Step 6: API Route Authentication
// api/protected.ts
import type { VercelRequest, VercelResponse } from '@vercel/node';
export default function handler(req: VercelRequest, res: VercelResponse) {
// Verify API key from header
const apiKey = req.headers['x-api-key'];
if (!apiKey || apiKey !== process.env.INTERNAL_API_KEY) {
return res.status(401).json({ error: 'Unauthorized' });
}
// Verify origin for CORS
const origin = req.headers.origin;
const allowedOrigins = (process.env.ALLOWED_ORIGINS ?? '').split(',');
if (origin && !allowedOrigins.includes(origin)) {
return res.status(403).json({ error: 'Forbidden origin' });
}
res.json({ data: 'protected content' });
}
Security Checklist
Check
Status
No secrets in NEXT_PUBLIC_* variables
Required
Sensitive env vars use type: sensitive
Required
Security headers configured
Required
HSTS enabled with preload
Recommended
Preview deployments protected
Recommended
Access tokens scoped and rotated
Required
CSP configured for your domains
Recommended
.env.local in .gitignore
Required
Output
Environment variables properly scoped and typed as sensitive
