Por framework
Segurança do Next.js — uma referência de hardening para produção
Uma referência de hardening do Next.js para produção: uma lista de verificação priorizada mais a fronteira servidor/cliente e as variáveis de ambiente, CVEs de dependências, autorização em Server Actions, SSRF, cabeçalhos/CSP e limitação de taxa, com uma lista de autoverificação. Defensivo, sem passos de ataque.
Para: qualquer pessoa que opere uma aplicação Next.js (App Router presumido). Sem passos de ataque aqui — esta é uma referência de trabalho para hardening: uma lista de verificação por ordem de prioridade, orientação por área e autoverificação. Para o panorama entre frameworks, veja o hub de segurança por framework.
Lista de verificação de hardening por ordem de prioridade
Faça esta tabela de cima para baixo. P0 é um pré-requisito, P1 é a fonte mais frequente de incidentes, P2 é higiene operacional contínua.
P0 ── Pré-requisito (faça primeiro)
Segredos apenas no servidor / monitoramento de CVEs de dependências + correção rápida / configuração de produção firme
P1 ── Principal fonte de incidentes
Autorização em Server Actions/Route Handlers + validação de entrada / SSRF em buscas do servidor
P2 ── Higiene operacional
Cabeçalhos/CSP / autenticação, sessão, cookies / limitação de taxa
| Prioridade | Controle | Especificidades (Next.js) |
|---|---|---|
| P0 | Segredos apenas no servidor | NEXT_PUBLIC_ só para valores seguros para o navegador; segredos apenas em Server Component/Action/Route Handler |
| P0 | CVEs de dependências | Monitore com npm audit/osv-scanner; julgue pela versão em execução, corrija rápido. Acompanhe RCE no núcleo |
| P0 | Configuração de produção | Rode um build de produção; não vaze detalhes internos (stack/env) em erros |
| P1 | Autorização de action | Autenticação + autorização com escopo de dono em cada Server Action/Route Handler |
| P1 | Validação de entrada | Valide entradas por esquema (tipo/faixa/permitido). Não confie no cliente |
| P1 | Proteção contra SSRF | Restrinja buscas de URL do lado do servidor a uma allowlist + bloqueie IPs internos/metadados. Limite os padrões remotos de imagem |
| P2 | Cabeçalhos/CSP | Cabeçalhos de segurança + HSTS no next.config. Considere uma CSP baseada em nonce no App Router |
| P2 | Autenticação/cookies | Cookies de sessão Secure/HttpOnly/SameSite. Não deixe a autorização apenas para o middleware |
| P2 | Limitação de taxa | Limites em autenticação, Server Actions e Route Handlers |
1. A fronteira servidor/cliente e as variáveis de ambiente (P0)
A maior fonte de incidentes do Next.js são segredos que deveriam ser apenas do servidor acabando no cliente.
- Só prefixe com
NEXT_PUBLIC_valores seguros para o navegador. Nunca em chaves de API ou informações de conexão (valoresNEXT_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 mantenha-os fora de
propse respostas (valores serializados). - Impeça que módulos apenas do servidor sejam importados pelo cliente (uma inclusão acidental pode empacotar segredos). Veja arquivos .env e segredos.
2. CVEs de dependências e o núcleo (P0)
- Monitore por máquina os CVEs de dependências (npm) com
npm auditou osv-scanner, julgue pela versão em execução e corrija rápido (decida com base no que está de fato instalado, não na declaração do package.json). - O núcleo do Next.js já teve RCEs sérios, então acompanhe rápido quando um é publicado. Para a disciplina operacional veja não ficar para trás nos CVEs; para a prática, o manual de resposta a vulnerabilidades.
- Mantenha Node/Next em versões suportadas e não deixe versões EOL no lugar.
3. Server Actions / Route Handlers (autorização + validação, P1)
Estes são pontos de entrada públicos do servidor. Poder ser chamado não significa que é permitido.
Comum (perigoso)
- actions tratadas como "logado = permitido"
- confiar apenas na autenticação do middleware, sem checagem de dono
- entrada passada ao BD ou a chamadas externas sem validação
- confiar em valores fornecidos pelo cliente (IDs, flags) como estão
Correto
- autenticação mais autorização com escopo de dono/permissão em cada action/handler
- não deixe para o middleware (autorize perto dos dados)
- valide por esquema a entrada (tipo/faixa/permitido)
- reverifique no servidor para que trocas de ID não funcionem
Veja o que é IDOR. Faça uma checagem de dono em cada caminho de leitura/atualização/exclusão.
4. SSRF e buscas do lado do servidor (P1)
A busca do lado do servidor de URLs fornecidas pelo usuário (proxies de imagem, webhooks, buscas de metadados) é uma entrada de SSRF.
- Restrinja os alvos a uma allowlist, e no momento da conexão bloqueie o alcance a IPs privados e metadados de nuvem (169.254.169.254).
- Mantenha os padrões remotos de otimização de imagem no mínimo (não permita a busca de hosts arbitrários).
- Veja o que é SSRF. Este site roteia as buscas de saída por um gateway seguro contra SSRF.
5. Injeção e saída
- XSS: o React escapa a saída por padrão. Não passe entrada do usuário para
dangerouslySetInnerHTML(só após sanitização se for realmente necessário). Veja o que é XSS. - SQL/injeção: faça bind com um ORM/placeholders; nunca construa consultas por concatenação de strings (→ o que é injeção de SQL).
- Não passe entrada externa para avaliação perigosa como
eval.
6. Cabeçalhos de segurança e CSP (P2)
- Defina cabeçalhos de segurança (X-Content-Type-Options, etc.) e HSTS no
next.config. Verifique o seu próprio site com o verificador de cabeçalhos de segurança. - No App Router, considere uma CSP baseada em nonce (evite permitir scripts inline em bloco). Note que coexistir com tags de analytics/anúncios exige design.
7. Autenticação, sessão, cookies (P2)
- Defina Secure / HttpOnly / SameSite nos cookies de sessão.
- Não delegue a autorização apenas à autenticação do middleware — o middleware é um complemento; verifique a decisão real na action/handler/camada de dados (alguns caminhos podem contornar o middleware).
- Regenere e expire sessões apropriadamente no login.
8. Limitação de taxa (P2)
- Aplique limites de tentativas/vazão a autenticação, Server Actions e Route Handlers para frear força bruta, abuso e DoS.
Verifique: o seu Next.js está de fato endurecido?
Construí-lo não é o fim — só está pronto depois que você verificou. Estas são autoverificações defensivas contra o seu próprio site/ambiente.
Nenhum segredo vazado para o cliente
NEXT_PUBLIC_.Produção não vaza detalhes internos em erros
A autorização de action se mantém
Cabeçalhos, dependências, SSRF
npm audit/osv está limpo, e que as buscas de saída não conseguem alcançar IPs internos.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 não é uma configuração chamativa, mas a fronteira servidor/cliente e a atualidade das dependências. Os segredos ficam no servidor, os pontos de entrada públicos (Server Actions/Route Handlers) sempre carregam autorização e validação de entrada, 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. As buscas de URL de saída passam por um gateway seguro contra SSRF para que não possam alcançar IPs internos ou metadados.
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 · XSS
- Ferramentas: verificador de cabeçalhos de segurança
FAQ
QO que devo fazer primeiro para proteger o Next.js?
Os três itens P0: (1) mantenha segredos apenas no servidor (só prefixe com NEXT_PUBLIC_ valores seguros para o navegador, nunca chaves de API ou informações de conexão); (2) monitore CVEs de dependências por máquina, julgue pela versão em execução e corrija rápido (incluindo RCE no núcleo); (3) firme a configuração de produção (rode um build de produção; não vaze detalhes internos em erros). Em seguida, passe para a autorização e a validação de entrada em Server Actions / Route Handlers, e a proteção contra SSRF.
QComo lido com variáveis de ambiente com segurança?
A regra é 'segredos ficam no servidor'. Só prefixe com NEXT_PUBLIC_ valores 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 dono, e sempre valide a entrada (por exemplo, validação de esquema). Não confie apenas na autenticação do middleware — faça a checagem de dono na action/handler também.
QComo me preparo para SSRF?
A entrada principal é a busca do lado do servidor de URLs fornecidas pelo usuário (proxies de imagem, webhooks, buscas de metadados). Restrinja os alvos a uma allowlist e, no momento da conexão, bloqueie o alcance a IPs privados e metadados de nuvem (169.254.169.254). Mantenha os padrões remotos de otimização de imagem no mínimo. Veja o glossário para o detalhe.
QComo gerencio vulnerabilidades de dependências npm?
Monitore por máquina os CVEs conhecidos com npm audit ou osv-scanner, julgue pela versão em execução e corrija rápido (decida com base no que está de fato instalado, não na declaração do package.json). O núcleo do Next.js já teve RCEs sérios, então acompanhar rápido importa. Mantenha também Node/Next em versões suportadas e não deixe versões EOL no lugar.