Sicurezza quando fai il deploy su Vercel

"Sicurezza su Vercel" si divide in due metà che conviene non mescolare. La prima è ciò che Vercel gestisce per te e ciò che ti lascia configurare nel pannello: protezione dei deploy, variabili per ambiente, firewall, ruoli del team. La seconda è ciò che Cursor, v0 o Bolt scrivono nel tuo progetto e che Vercel pubblica così com'è, con le sue chiavi pubbliche e le sue rotte senza protezione. Questa guida spiega il modello di Vercel, ripassa ciò che l'IA sbaglia nel fare il deploy lì, ti lascia un vercel.json pronto da incollare, un prompt di revisione e quattro verifiche dall'esterno. Il dettaglio di ogni difetto è in sicurezza nel deploy su Vercel.

Parte 1: come funziona la sicurezza su Vercel

Cosa Vercel fa da solo

Certificato TLS emesso e rinnovato automaticamente, reindirizzamento da HTTP a HTTPS, funzioni serverless isolate tra progetti, rete globale con mitigazione DDoS e un registro di ogni deploy con chi l'ha fatto e da quale commit. Niente di tutto questo va configurato. Mette anche un header perché i motori di ricerca non indicizzino le anteprime.

Cosa è configurazione tua

• Deployment Protection. Di default le anteprime sono pubbliche per chiunque abbia l'URL. In Settings puoi richiedere un account Vercel del team (gratis), una password (piani a pagamento) o limitare per IP. È la prima casella da attivare.
• Variabili d'ambiente per ambiente. Ogni variabile viene assegnata a Production, Preview o Development. Le chiavi di produzione non dovrebbero esistere in Preview, e quelle sensibili si marcano come Sensitive perché non si possano più rileggere dal pannello.
• Firewall. Vercel Firewall porta regole gestite, una modalità di sfida contro i bot e regole proprie di rate limit per IP o per rotta. Si attivano dal pannello senza toccare il codice e sono la risposta a "qualcuno sta consumando la mia quota OpenAI".
• Git e deploy. Ogni push su qualsiasi branch fa il deploy. Proteggi il branch di produzione su GitHub, controlla quali account hanno accesso al progetto e imponi l'autenticazione a due fattori nel team.
• Token e servizi. I token della CLI, quelli di Vercel Blob o quelli dei database integrati sono segreti di server. Un token Vercel con ambito team fa il deploy di quello che vuole in tutti i tuoi progetti.

Cosa dipende dal framework, non da Vercel

Quali variabili arrivano al browser (NEXT_PUBLIC_, VITE_, NUXT_PUBLIC_), se si pubblicano le source map e quali header si inviano lo decidono il tuo framework e la tua configurazione, non la piattaforma. Vercel esegue solo la build. Per questo due app su Vercel possono avere una A e una F negli header.

Parte 2: cosa l'IA sbaglia nel deploy su Vercel

• Chiavi segrete con prefisso pubblico perché il componente "ne aveva bisogno". Viaggiano nel bundle verso tutti i visitatori. Cerca sk_live, service_role o AKIA nei tuoi chunk.
• Rotte di test pubblicate. /api/debug, /api/seed o /api/admin create per provare e messe in produzione senza autenticazione.
• Cron senza segreto. Vercel chiama la tua rotta cron con un header Authorization che porta il tuo CRON_SECRET; se l'handler non lo controlla, chiunque lancia il task.
• Funzioni senza limiti. Un endpoint che chiama un modello o invia email senza tetto per utente né regola di firewall.
• File in public/. Un .env copiato, un backup.json, un config.yml. Tutto ciò che sta in quella cartella è pubblico.
• CORS con wildcard e credenziali sulle rotte API, perché "così funzionava da localhost".
• Senza vercel.json. Né header di sicurezza né reindirizzamento del dominio .vercel.app al tuo, che resta duplicato su Google.

Un vercel.json pronto da incollare

Header di sicurezza per tutte le rotte e reindirizzamento del sottodominio Vercel al tuo dominio. Sostituisci i due nomi e, se usi Next.js, puoi mettere gli header in next.config al posto suo:

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Strict-Transport-Security", "value": "max-age=63072000; includeSubDomains; preload" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()" }
      ]
    }
  ],
  "redirects": [
    {
      "source": "/(.*)",
      "has": [{ "type": "host", "value": "mio-progetto.vercel.app" }],
      "destination": "https://tuodominio.com/$1",
      "permanent": true
    }
  ]
}

La Content-Security-Policy va a parte perché dipende dai tuoi script; inizia in modalità report come spiega header di sicurezza HTTP.

Un prompt di revisione prima del deploy

Rivedi la sicurezza di questo progetto pubblicato su Vercel e non cambiare ancora nulla. Rispondi con una lista:
1. Variabili con prefisso pubblico (NEXT_PUBLIC_, VITE_, NUXT_PUBLIC_) che contengono chiavi segrete.
2. Rotte API senza controllo della sessione, rotte di test o debug, e rotte cron che non verificano CRON_SECRET.
3. Endpoint che chiamano servizi a pagamento senza limite per utente.
4. File in public/ che non dovrebbero essere pubblici.
5. Rotte API con Access-Control-Allow-Origin: * e credenziali.
6. Se esiste vercel.json o next.config con header di sicurezza e se le source map sono disattivate in produzione.
Per ogni punto, proponi la modifica esatta e aspetta la mia conferma.

Verifica il risultato dall'esterno

curl -sI https://tuodominio.com | grep -iE "strict-transport|x-frame|x-content-type|content-security"
curl -sI https://mio-progetto.vercel.app | grep -iE "^HTTP|^location"
curl -sI https://mio-progetto-git-main-team.vercel.app | grep -iE "^HTTP"
for p in .env .env.local config.json backup.zip api/debug api/seed; do printf "%-14s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://tuodominio.com/$p"; done

L'atteso: header presenti, un 301 verso il tuo dominio sull'URL .vercel.app, un 401 sull'URL di anteprima se la protezione è attiva, e 404 su tutte le rotte della lista. Scanaris fa queste verifiche e una quarantina di altre in 30 secondi: rileva che l'app è su Vercel e con quale framework, cerca segreti nel bundle, controlla source map, header, CSP, cookie, CORS, TLS e file esposti, e ti dà un fix prompt per ogni errore da incollare in Cursor, v0 o Bolt. Se la tua app è Next.js, la guida Next.js spiega quale codice gira sul server e cosa arriva al browser.

Domande frequenti

Le anteprime di Vercel sono private?

Non di default: chiunque abbia l'URL le apre, anche se non vengono indicizzate. Attiva Vercel Authentication in Deployment Protection; è disponibile nel piano gratuito.

Vercel protegge le mie rotte API?

No. Una rotta API è un URL pubblico; la sessione la controlli tu nel codice. Il firewall può limitare le richieste e frenare i bot, ma non decide chi è autorizzato.

Mi serve vercel.json se uso Next.js?

Per gli header no: next.config ha la funzione headers(). Per il reindirizzamento del dominio .vercel.app al tuo puoi usare uno qualsiasi dei due. L'importante è che esista in uno dei due.