Vercel security checklist for AI-built apps

Everything that reaches the browser is public: static files, client components and any variable whose name carries the framework's public prefix. In Next.js that prefix is NEXT_PUBLIC_, and Next.js inlines those values into client code. Everything else runs on the server side of Vercel, where environment variables live.

Vercel stores environment variables encrypted at rest but they are visible to anyone with access to the project. That makes team membership part of your trust boundary. For general secret-handling ideas see our environment variables guide. Below is what to verify on Vercel itself.

Each variable can apply to Production, Preview, Development and custom environments. Use the narrowest set. A production database key in Preview means every branch deploy, and everyone who can push a branch, touches production data. Changes only affect new deployments, so redeploy after editing.

Mark secrets Sensitive. Vercel stores those in an unreadable format and redacts them from build logs when they are long enough, though only for Production and Preview. Owners can enforce this for all new variables in team security settings.

vercel env ls
vercel env pull .env.check
grep -rnE "sk_live_|sb_secret_|service_role|BEGIN PRIVATE KEY" .next/static

Deployment Protection controls who can open your URLs. Standard Protection covers everything except production domains and is the documented recommendation for most projects. Vercel Authentication limits access to Vercel users with access, while Password Protection and Trusted IPs are paid options on some plans. Choose All Deployments if the whole app is private.

After enabling Standard Protection, generated production deployment URLs become restricted, so server code that calls itself through VERCEL_URL may need to use the requested origin instead.

Add headers in vercel.json or your framework config. Start Content-Security-Policy in report-only mode, as Vercel's guidance suggests, then enforce once nothing breaks, and avoid unsafe-inline and unsafe-eval where you can.

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Content-Security-Policy-Report-Only", "value": "default-src 'self'" }
      ]
    }
  ]
}

Next.js documents that an exported server action is reachable by a direct POST request, not only through your UI. A check on the page does not cover the action, so authenticate inside it, then check that the user owns the record. Return only the fields the client needs. The same documentation says route.ts files deserve traditional auditing.

Put data access in a server-only module that performs authorization and returns minimal objects, and validate every argument.

"use server";

import { auth } from "@/lib/auth";
import { db } from "@/lib/db";

export async function deletePost(postId: string) {
  const session = await auth();
  if (!session?.user) throw new Error("Unauthorized");
  const post = await db.post.findUnique({ where: { id: postId } });
  if (!post || post.authorId !== session.user.id) throw new Error("Forbidden");
  await db.post.delete({ where: { id: postId } });
}

Confirm headers on production, and confirm a route returns an error without a session. Run these against your own deployment only.

curl -sI https://your-app.example.com | grep -iE "content-security|x-frame|x-content-type|referrer"
curl -i https://your-app.example.com/api/your-route

Function logs are visible to teammates and often flow to third-party tools. Log identifiers and outcomes, not tokens, cookies, request bodies or health data. Search recent logs for the prefixes of your provider keys, and rotate anything you find.

• Naming a secret NEXT_PUBLIC_ because the client needed it, which publishes it.
• Sharing one production database key across Production and Preview.
• Assuming a page redirect protects the server action defined on it.
• Leaving preview URLs public while they point at real data.
• Setting headers only in development config that never reaches production.
• Passing whole database rows to client components.

After each dependency update or AI-generated change, re-run vercel env ls, the header check and the no-session route calls. Review any new use server file for the two checks above.