Por framework
Segurança do Spring Boot — uma referência de hardening para produção
Uma referência de hardening do Spring Boot para produção: um checklist priorizado mais CVEs de dependências (Log4Shell), configuração/segredos de produção, autorização no Spring Security, exposição do Actuator, desserialização e SSRF. Defensivo, sem passos de ataque.
Para: qualquer pessoa que opere uma aplicação Java / Spring Boot. Sem passos de ataque aqui — esta é uma referência de trabalho para hardening: um checklist priorizado, orientação por área e autoverificação. Para o panorama entre frameworks, veja o hub de segurança por framework.
Checklist de hardening priorizado
Faça esta tabela de cima para baixo. P0 é pré-requisito, P1 é a fonte mais frequente de incidentes, P2 é higiene operacional contínua.
P0 ── Pré-requisito (faça primeiro)
Monitoramento de CVEs de dependências + correção rápida / sem detalhe de erro em produção / externalizar segredos
P1 ── Principal fonte de incidentes
Autorização no Spring Security (negação por padrão, checagens de dono) / reduzir a exposição do Actuator e do gerenciamento
P2 ── Higiene operacional
Desserialização insegura / cabeçalhos, CSRF, sessão / SSRF
| Prioridade | Controle | Especificidades (Spring Boot) |
|---|---|---|
| P0 | Monitoramento de CVEs de dependências | osv-scanner / dependency-check; julgue pela versão em execução, corrija rápido (classe Log4Shell) |
| P0 | Erros de produção | Não exponha stack traces (server.error.include-stacktrace=never, etc.) |
| P0 | Externalizar segredos | Informações de conexão/chaves via env/Vault, não configuração escrita diretamente. Não faça commit no repositório |
| P1 | Autorização explícita | Negação por padrão + segurança de método (@PreAuthorize) + checagens de dono |
| P1 | Reduzir exposição do Actuator | Exposição mínima (por ex. health) + autenticação exigida + porta/fronteira separada. Não exponha env/heapdump |
| P1 | Desserialização | Não desserialize nativamente dados não confiáveis. Não deixe o SpEL avaliar a entrada |
| P2 | Injeção | Vincule com JPA/JdbcTemplate. Nunca construa consultas por concatenação de strings |
| P2 | Cabeçalhos/CSRF/sessão | Cabeçalhos do Spring Security (HSTS, etc.), CSRF, atributos de cookie, fixação de sessão |
| P2 | SSRF | Lista de permissão para buscas do lado do servidor + bloqueio de IPs internos/metadados |
1. CVEs de dependências e o ecossistema (P0)
Justamente porque o Spring é tão usado, uma falha de biblioteca de dependência cascateia para todos de uma vez. O Log4Shell é o símbolo disso.
- Monitore por máquina os CVEs de dependências com osv-scanner ou OWASP dependency-check, julgue pela versão em execução e corrija rápido (decida pelo que está realmente compilado, não pela declaração no pom.xml/gradle).
- Mantenha o Spring Boot e o Java em versões suportadas. Não deixe versões EOL em produção.
- Para o caso e a prática, veja a dissecação do Log4Shell · o manual de resposta a vulnerabilidades · monitorar CVEs de dependências.
2. Configuração de produção e segredos (P0)
- Em produção, não exponha detalhes de erro (stack traces) — reduza as pistas que vazam a estrutura interna e as versões de dependências.
- Mantenha segredos como informações de conexão e chaves fora do application.properties/yml, injetando-os a partir de env ou de um gerenciador de segredos (Vault, etc.). Não faça commit deles no repositório (→ arquivos .env e segredos).
- Não habilite ferramentas de desenvolvimento (devtools, etc.) em produção.
3. Autorização no Spring Security (P1 — a principal fonte)
Comum (perigoso)
- padrões frouxos, não projetados como permissão explícita
- protegido apenas por padrões de URL, sem checagem de método/dono
- autenticado, mas "logado = permitido"
- uma lacuna de configuração deixa algum endpoint passar
Correto
- negação por padrão (só passa o que você permite explicitamente)
- autorização de método (
@PreAuthorize, etc.) + checagens de dono - verifique permissão/dono em todo caminho de leitura/atualização/exclusão
- construa a autorização explicitamente, sem deixar aos padrões
Veja o que é IDOR. Autenticação e autorização são diferentes; autorize perto dos dados.
4. Actuator e endpoints de gerenciamento (P1)
- Restrinja os endpoints do Actuator expostos ao mínimo (por exemplo, apenas health).
- Exija autenticação/autorização e mantenha-os em uma porta separada / fronteira de rede inalcançável de fora.
- Não exponha endpoints sensíveis como
env,heapdumpouloggers(vazamento de informação / trampolim para operações).
5. Desserialização insegura e avaliação de expressões (P2)
- Não desserialize nativamente dados não confiáveis (pode levar a RCE sob as condições certas). Verifique a procedência e restrinja a um formato seguro como JSON onde necessário (→ o que é RCE).
- Não deixe templates ou o SpEL avaliarem a entrada do usuário. Valide a entrada com Bean Validation, etc.
6. Injeção e acesso a dados (P2)
- SQL: vincule com JPA / JdbcTemplate; nunca construa consultas por concatenação de strings (→ o que é injeção de SQL).
- Ao emitir HTML a partir de um template, aplique codificação de saída e não incorpore a entrada do usuário diretamente (defesa contra XSS).
7. Cabeçalhos, HTTPS, sessão (P2)
- Use os cabeçalhos de segurança do Spring Security (HSTS em HTTPS, etc.). Verifique o seu próprio site com o verificador de cabeçalhos de segurança.
- Force HTTPS. Atrás de um balanceador de carga, configure-o para detectar o esquema/IP de cliente correto.
- Defina Secure/HttpOnly/SameSite nos cookies, mantenha a proteção CSRF (ativa por padrão em sessões de navegador; se você a desabilitar para APIs, combine com proteções alternativas) e regenere a sessão no login.
8. SSRF e buscas do lado do servidor (P2)
- A busca, do lado do servidor, de URLs fornecidas pelo usuário deve restringir os alvos a uma lista de permissão e bloquear o alcance a IPs internos / metadados de nuvem no momento da conexão (→ o que é SSRF).
Verifique: o seu Spring Boot está mesmo endurecido?
Construí-lo não é o fim — só está pronto quando você verificou. Estas são autoverificações defensivas contra o seu próprio ambiente.
O Actuator não está expondo endpoints sensíveis
/actuator não expõe env/heapdump, etc., e que está autenticado.Os erros não vazam informações internas
A autorização se sustenta
Dependências e cabeçalhos
A visão deste site: sobre uma base endurecida, dependências e superfície decidem
O Spring é uma base sólida, mas justamente por ser tão usado, uma falha de biblioteca de dependência cascateia para todos de uma vez. O Log4Shell é o símbolo disso, e a defesa central é menos uma configuração específica do que o hábito operacional de monitorar dependências por máquina, julgar pela versão em execução e corrigir rápido. Junto a isso, mantenha os endpoints de gerenciamento úteis (Actuator) fora da superfície pública e não deixe a autorização aos padrões. Este site é uma stack diferente, mas o princípio é idêntico — atualização das dependências, superfície pública mínima, autorização explícita funcionam independentemente do framework.
Leia a seguir
- Hub: segurança por framework · segurança do Next.js
- Caso/prática: a dissecação do Log4Shell · o manual de resposta a vulnerabilidades · monitorar CVEs de dependências
- Glossário: o que é IDOR · o que é RCE · o que é SSRF
- Ferramentas: verificador de cabeçalhos de segurança
FAQ
QO que devo fazer primeiro para proteger o Spring Boot?
Os três itens P0: (1) monitorar por máquina os CVEs de dependências e corrigir rápido, julgando pela versão em execução (com o Log4Shell, uma biblioteca de base cascateia para muitas aplicações de uma vez, então acompanhar importa); (2) não expor erros detalhados (stack traces) em produção; (3) externalizar segredos (informações de conexão, chaves) em vez de escrevê-los diretamente na configuração. Em seguida, avance para a autorização no Spring Security e a redução da exposição do Actuator.
QO que devo observar no Actuator?
O Actuator oferece endpoints de gerenciamento para informações de runtime e diagnóstico, mas, se exposto, pode vazar informações internas e, dependendo da configuração, virar um trampolim para operações. Em produção, restrinja a exposição ao mínimo (por exemplo, apenas health), exija autenticação e autorização e mantenha-o em uma porta separada / fronteira de rede inalcançável de fora. Não exponha endpoints sensíveis como env, heapdump ou loggers.
QComo me preparo para uma falha de dependência como o Log4Shell?
O Log4Shell é o caso clássico da falha de uma biblioteca de logging amplamente herdada cascateando para muitas aplicações de uma vez. A preparação central é monitorar por máquina os CVEs de dependências e corrigir rápido, julgando pela versão em execução (osv-scanner, OWASP dependency-check, etc.) — decida pela versão realmente compilada, não pela declaração no pom.xml/gradle. Privilégio mínimo e segmentação de rede também reduzem o raio de explosão.
QComo devo escrever a autorização no Spring Security com segurança?
Incline o padrão para negar (só passa o que você permite explicitamente), não confie apenas em padrões de URL e use autorização em nível de método (@PreAuthorize, etc.) onde apropriado. Além do login (autenticação), implemente uma checagem de dono de que o recurso-alvo realmente pertence ao usuário. Lacunas de configuração viram buracos de escalonamento de privilégio, então construa a autorização explicitamente.
QPor que a desserialização insegura é perigosa?
Restaurar dados não confiáveis via desserialização nativa do Java pode, sob as condições certas, levar à execução remota de código (RCE). Não restaure dados de origem externa como estão — verifique a procedência e restrinja a um formato seguro como JSON onde necessário. Da mesma forma, não deixe templates ou a linguagem de expressão (SpEL) avaliarem a entrada do usuário.