Vercel

Vercel Security Best Practices

Secure your Vercel + Next.js deployments. From the NEXT_PUBLIC_ prefix trap to Server Action authorization gaps.

Verify your app follows these best practices automatically.

Vercel's tight integration with Next.js creates a unique security surface. The NEXT_PUBLIC_ prefix silently exposes variables to the browser, Server Actions can be called directly by anyone, and Edge Middleware runs before your app — making it both a security tool and an attack surface. These practices cover Vercel-specific risks beyond generic deployment security.

Quick Wins

Search .env files for NEXT_PUBLIC_ variables containing 'secret', 'sk_', or 'password'

Enable Deployment Protection for all preview environments

Add security headers in next.config.js headers() function

Test every Server Action by calling it directly with fetch — verify it checks auth

Review git history for accidentally committed secrets: git log -p --all -S 'sk_'

Security Best Practices

#1Never Put Secrets in NEXT_PUBLIC_ Variables

critical

The NEXT_PUBLIC_ prefix inlines variables into your client JavaScript bundle at build time. Any variable with this prefix is visible to all users in the browser.

Implementation

Only use NEXT_PUBLIC_ for truly public values (API URLs, site names). Keep secrets in unprefixed variables accessible only in server components and API routes.

Don't do this

NEXT_PUBLIC_STRIPE_SECRET=sk_live_abc123

Do this instead

STRIPE_SECRET=sk_live_abc123
NEXT_PUBLIC_STRIPE_PUBLISHABLE=pk_live_abc123

#2Validate Authorization in Server Actions

critical

Next.js Server Actions can be invoked directly via POST requests — they're not protected by the UI that triggers them. Every Server Action must validate the caller's identity and permissions.

Implementation

Check session validity and resource ownership at the start of every Server Action, not just in the component that calls it

#3Scope Environment Variables to Correct Environments

critical

Vercel lets you set different values for Production, Preview, and Development. Using the same production keys in Preview means any preview deployment can access production data.

Implementation

In Vercel Dashboard → Environment Variables, set environment-specific values. Use staging API keys for Preview.

#4Enable Deployment Protection for Previews

high

Every git push creates a public preview URL. Without protection, unreleased features, staging data, and test accounts are accessible to anyone.

Implementation

Project Settings → Deployment Protection → Enable for Preview. Choose Vercel Authentication or password protection.

#5Use Edge Middleware for Security Checks

high

Vercel Edge Middleware runs before your app handles the request. Use it for authentication, geo-blocking, and bot detection — it executes faster than API routes.

Implementation

Add middleware.ts at your project root to check auth tokens, block suspicious IPs, or redirect unauthenticated users

#6Enable Vercel Firewall Rules

medium

Vercel Firewall provides rate limiting and IP blocking at the edge, before requests reach your application.

Implementation

Dashboard → Firewall → Add rules for rate limiting on auth endpoints and blocking known malicious IPs

Common Mistakes to Avoid

Secrets in NEXT_PUBLIC_ variables

Why it's dangerous:

NEXT_PUBLIC_ inlines values into the client bundle at build time — visible to every user in DevTools

How to fix:

Remove the NEXT_PUBLIC_ prefix. Access the variable only in server components, API routes, or Server Actions

Server Actions without authorization checks

Why it's dangerous:

Server Actions are callable via direct POST requests — the UI button is not a security boundary

How to fix:

Add getServerSession() or equivalent auth check at the start of every Server Action

Production API keys in Preview deployments

Why it's dangerous:

Anyone with a preview URL can trigger actions against production databases and services

How to fix:

Use Vercel's per-environment variable scoping to set staging keys for Preview

Verify Your Vercel App Security

Following best practices is the first step. Verify your app is actually secure with a comprehensive security scan.

Get Starter Scan

Frequently Asked Questions

Are my environment variables secure on Vercel?

Yes, Vercel encrypts them at rest and in transit. The risk is the NEXT_PUBLIC_ prefix — it embeds the value in your client JavaScript bundle. Only use NEXT_PUBLIC_ for values that are intentionally public.

Do Server Actions need separate security checks?

Yes. Server Actions are exposed as POST endpoints that anyone can call directly with fetch or curl. The UI component that triggers them provides no security. Validate authentication and authorization inside every Server Action.

How is Vercel security different from Netlify?

Vercel's main risk is the NEXT_PUBLIC_ prefix silently exposing variables and Server Actions being directly callable. Netlify's risks center on build-time variable embedding and Netlify Functions needing explicit auth. Both require preview protection, but the specific mechanisms differ.

Related Vercel Security Resources

Vercel Security Overview Vercel Security Issues Vercel Security Risks Is Vercel Safe?

Similar Platforms

Netlify Best Practices Railway Best Practices Render Best Practices

Last updated: January 2026