Por framework
Segurança do Next.js — Server Actions, variáveis de ambiente e CVEs de dependências
Os incidentes do Next.js acontecem na fronteira servidor/cliente: exposição de variáveis de ambiente (segredos server-only enviados ao cliente), autorização ausente em Server Actions e CVEs de dependências conhecidas. Mantenha segredos no servidor, restrinja por dono, monitore CVEs. Defensivo, sem passos de ataque.
Para: qualquer pessoa que opere uma aplicação Next.js. Sem passos de ataque aqui — apenas os incidentes que acontecem na fronteira servidor/cliente e como fechá-los. Para o panorama completo, veja o hub de segurança por framework.
Os três grandes riscos (na fronteira)
O escape e o roteamento do Next.js são excelentes, mas estes três são seus para fechar, cuidando da fronteira.
① Exposição de variáveis de ambiente
Uso incorreto de NEXT_PUBLIC_ ou segredos enviados ao cliente. Embutidos no bundle, visíveis aos visitantes.
② Falhas de autorização em actions
Sem checagem de dono em Server Actions / Route Handlers. Troque um ID, opere sobre dados de outro usuário.
③ CVEs de dependências conhecidas
CVEs de núcleo/dependências (incl. RCE) sem correção. Julgue pela versão em execução, corrija rápido.
Como fechá-los (3 passos)
Mantenha segredos no servidor
NEXT_PUBLIC_ apenas valores seguros para o navegador; nunca em chaves de API ou informações de conexão. Leia segredos apenas dentro de server components / Server Actions / Route Handlers e mantenha-os fora de props e respostas. (→ arquivos .env e segredos)Autorize em cada Server Action / Route Handler
Monitore CVEs de dependências por máquina e corrija rápido
Comum (perigoso)
- segredos prefixados com
NEXT_PUBLIC_, expostos ao cliente - Server Actions tratadas como "logado = permitido"
- busca de URLs externas no servidor sem proteção (SSRF)
- CVEs de dependências conhecidas sem correção
Correto
- segredos são server-only, nunca enviados ao cliente
- actions fazem autorização com escopo de dono
- buscas de URL passam por proteção contra SSRF (bloqueia IPs internos, allowlist)
- CVEs de dependências monitoradas por máquina + corrigidas rápido
A visão deste site: gerencie 'a fronteira e as dependências', não o núcleo
Este site roda sobre Next.js, e o centro de gravidade que de fato protegemos não é uma configuração chamativa, mas a fronteira servidor/cliente e a atualização das dependências. Os segredos ficam no servidor, os pontos de entrada públicos (Server Actions / Route Handlers) sempre carregam autorização, e as dependências passam por uma auditoria de CVEs antes de cada deploy. Nossa própria origem foi um incidente de "CVE sem correção explorado automaticamente", então monitorar dependências por máquina é um hábito de prioridade máxima. Qualquer código que busque uma URL externa passa pelo nosso próprio gateway seguro contra SSRF, de modo que não alcance IPs internos ou metadados (→ o que é SSRF).
Leia a seguir
- Hub: segurança por framework · segurança do Laravel
- Dependências: não ficar para trás nos CVEs · o manual de resposta a vulnerabilidades
- Glossário: o que é IDOR · o que é SSRF · arquivos .env e segredos
FAQ
QO Next.js é um framework seguro?
O Next.js tem padrões seguros (escape de saída, etc.) e é bastante sólido de fábrica. Mas os incidentes não vêm dos padrões do núcleo, e sim de como você lida com a fronteira servidor/cliente: segredos que deveriam ser server-only acabando no cliente, esquecer a autorização em Server Actions e deixar CVEs de dependências conhecidas sem correção. Você não pode confiar só nos padrões — a fronteira e as dependências você mesmo gerencia.
QComo lido com variáveis de ambiente com segurança?
A regra é 'segredos ficam no servidor'. Só prefixe valores com NEXT_PUBLIC_ se forem seguros para o navegador; nunca em chaves de API ou informações de conexão (valores NEXT_PUBLIC_ são embutidos no bundle do cliente no build e ficam visíveis para os visitantes). Leia segredos apenas dentro de server components / Server Actions / Route Handlers, e projete de modo que eles nunca escapem para props ou respostas.
QO que devo observar em Server Actions?
Server Actions e Route Handlers são pontos de entrada públicos do servidor. Poder ser chamado não significa que é permitido. Além do login (autenticação), escreva uma autorização que restrinja cada operação ao usuário dono do alvo. Esqueça isso e alguém pode atualizar ou apagar os dados de outro usuário só trocando um ID (autenticação ≠ autorização). Valide a entrada e sempre faça a checagem de dono na action.