Segurança ao fazer deploy na Vercel

"Segurança na Vercel" divide-se em duas metades que convém não misturar. A primeira é o que a Vercel gere por ti e o que te deixa configurar no painel: proteção de deploys, variáveis por ambiente, firewall, papéis da equipa. A segunda é o que o Cursor, o v0 ou o Bolt escrevem no teu projeto e que a Vercel publica tal e qual, com as suas chaves públicas e as suas rotas sem proteção. Este guia explica o modelo da Vercel, repassa o que a IA faz mal ao fazer deploy lá, deixa-te um vercel.json pronto a colar, um prompt de revisão e quatro verificações de fora. O detalhe de cada falha está em segurança ao fazer deploy na Vercel.

Parte 1: como funciona a segurança na Vercel

O que a Vercel faz sozinha

Certificado TLS emitido e renovado automaticamente, redirecionamento de HTTP para HTTPS, funções serverless isoladas entre projetos, rede global com mitigação de DDoS e um registo de cada deploy com quem o fez e a partir de que commit. Nada disto tens de configurar. Também põe um cabeçalho para que os motores de busca não indexem as pré-visualizações.

O que é configuração tua

• Deployment Protection. Por defeito as previews são públicas para quem tiver o URL. Em Settings podes exigir conta Vercel da equipa (grátis), palavra-passe (planos pagos) ou limitar por IP. É a primeira caixa a ativar.
• Variáveis de ambiente por ambiente. Cada variável é atribuída a Production, Preview ou Development. As chaves de produção não deviam existir em Preview, e as sensíveis marcam-se como Sensitive para não poderem voltar a ser lidas a partir do painel.
• Firewall. A Vercel Firewall traz regras geridas, um modo de desafio contra bots e regras próprias de limite de pedidos por IP ou por rota. Ativam-se a partir do painel sem tocar no código e são a resposta a "alguém está a gastar a minha quota da OpenAI".
• Git e deploys. Cada push a qualquer ramo faz deploy. Protege o ramo de produção no GitHub, revê que contas têm acesso ao projeto e obriga à autenticação de dois fatores na equipa.
• Tokens e serviços. Os tokens da CLI, os do Vercel Blob ou os das bases de dados integradas são segredos de servidor. Um token da Vercel com âmbito de equipa faz deploy do que quiser em todos os teus projetos.

O que depende da framework, não da Vercel

Que variáveis chegam ao navegador (NEXT_PUBLIC_, VITE_, NUXT_PUBLIC_), se se publicam source maps e que cabeçalhos se enviam é a tua framework e a tua configuração que decidem, não a plataforma. A Vercel só executa o build. Por isso duas apps na Vercel podem ter um A e um F em cabeçalhos.

Parte 2: o que a IA faz mal ao fazer deploy na Vercel

• Chaves secretas com prefixo público porque o componente "precisava delas". Viajam no bundle para todos os visitantes. Procura sk_live, service_role ou AKIA nos teus chunks.
• Rotas de teste publicadas. /api/debug, /api/seed ou /api/admin criadas para testar e enviadas para produção sem autenticação.
• Cron sem segredo. A Vercel chama a tua rota de cron com um cabeçalho Authorization que leva o teu CRON_SECRET; se o handler não o verifica, qualquer pessoa dispara a tarefa.
• Funções sem limite. Um endpoint que chama um modelo ou envia emails sem teto por utilizador nem regra de firewall.
• Ficheiros em public/. Um .env copiado, um backup.json, um config.yml. Tudo o que está nessa pasta é público.
• CORS com wildcard e credenciais nas rotas de API, porque "assim funcionava a partir do localhost".
• Sem vercel.json. Nem cabeçalhos de segurança nem redirecionamento do domínio .vercel.app para o domínio próprio, que fica duplicado no Google.

Um vercel.json pronto a colar

Cabeçalhos de segurança para todas as rotas e redirecionamento do subdomínio da Vercel para o teu domínio. Substitui os dois nomes e, se usas Next.js, podes pôr os cabeçalhos no next.config em vez disso:

{
  "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": "o-meu-projeto.vercel.app" }],
      "destination": "https://oteudominio.com/$1",
      "permanent": true
    }
  ]
}

A Content-Security-Policy vai à parte porque depende dos teus scripts; começa em modo relatório como explica cabeçalhos de segurança HTTP.

Um prompt de revisão antes de fazer deploy

Revê a segurança deste projeto publicado na Vercel e não mudes nada ainda. Responde com uma lista:
1. Variáveis com prefixo público (NEXT_PUBLIC_, VITE_, NUXT_PUBLIC_) que contenham chaves secretas.
2. Rotas de API sem verificação de sessão, rotas de teste ou depuração, e rotas de cron que não verifiquem CRON_SECRET.
3. Endpoints que chamem serviços pagos sem limite por utilizador.
4. Ficheiros em public/ que não devam ser públicos.
5. Rotas de API com Access-Control-Allow-Origin: * e credenciais.
6. Se existe vercel.json ou next.config com cabeçalhos de segurança e se os source maps estão desativados em produção.
Para cada ponto, propõe a alteração exata e espera pela minha confirmação.

Verifica o resultado de fora

curl -sI https://oteudominio.com | grep -iE "strict-transport|x-frame|x-content-type|content-security"
curl -sI https://o-meu-projeto.vercel.app | grep -iE "^HTTP|^location"
curl -sI https://o-meu-projeto-git-main-equipa.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://oteudominio.com/$p"; done

O esperado: cabeçalhos presentes, um 301 para o teu domínio no URL .vercel.app, um 401 no URL de preview se a proteção estiver ativa, e 404 em todas as rotas da lista. O Scanaris faz estas verificações e cerca de quarenta mais em 30 segundos: deteta que a app está na Vercel e com que framework, procura segredos no bundle, verifica source maps, cabeçalhos, CSP, cookies, CORS, TLS e ficheiros expostos, e dá-te um fix prompt por cada falha para colar no Cursor, no v0 ou no Bolt. Se a tua app é Next.js, o guia de Next.js explica que código corre no servidor e o que chega ao navegador.

Perguntas frequentes

As pré-visualizações da Vercel são privadas?

Não por defeito: qualquer pessoa com o URL abre-as, embora não sejam indexadas. Ativa Vercel Authentication em Deployment Protection; está disponível no plano gratuito.

A Vercel protege as minhas rotas de API?

Não. Uma rota de API é um URL público; a sessão verifica-la tu no código. A firewall pode limitar pedidos e travar bots, mas não decide quem está autorizado.

Preciso de vercel.json se uso Next.js?

Para os cabeçalhos não: o next.config tem a função headers(). Para o redirecionamento do domínio .vercel.app para o teu podes usar qualquer um dos dois. O importante é que exista num deles.