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 é manutenção 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 ── Manutenção contínua
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)
Estas são funções do lado do servidor que qualquer pessoa pode chamar. 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) é onde o SSRF costuma acontecer.
- 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: foque na fronteira servidor/cliente e nas dependências
Este site roda sobre Next.js, e o foco não é uma configuração especial, mas a fronteira servidor/cliente e manter as dependências atualizadas. Os segredos ficam no servidor, as funções que qualquer pessoa pode chamar (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. Este site nasceu depois de um incidente em que um CVE sem correção foi 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
Fontes e escopo
Estas fontes primárias fundamentam as configurações, o escopo ou as medidas acima; links conferidos em 23 de outubro de 2026. Confira as condições de versão e configuração. As prioridades e lições são orientações deste site, não uma revalidação completa nem garantia de segurança.