«Segurança do Laravel», «hardening do WordPress» — quando pesquisamos, procuramos respostas por tecnologia. Esta página é o ponto de entrada para a defesa por framework (sem passos de ataque).
Compartilhado (igual em todos os frameworks)
controle de acesso, segredos, injeção, CVEs de dependências, configuração incorreta. As defesas básicas também são compartilhadas.
Específico do framework (cada capítulo)
os «padrões perigosos» e «o ponto mais visado». Esta é a única parte que muda conforme a tecnologia.
Tipos de fraqueza compartilhados por todos os frameworks
Primeiro o panorama geral. Estes tipos são visados repetidamente, independentemente da tecnologia; cada capítulo de framework explica como eles aparecem naquela tecnologia.
Guias por framework
Leia o capítulo da sua tecnologia. Cada um segue «perigos padrão → ponto mais visado → passos de hardening».
WordPress
Laravel
Next.js
Java / Spring
Outros frameworks
Configurações para verificar primeiro em produção (tabela rápida por framework)
Em qualquer framework, verifique primeiro duas coisas: se a produção mostra erros detalhados e onde ficam os seus segredos. Os nomes das configurações mudam, então encontre a sua linha abaixo. Os nomes foram conferidos com a documentação oficial atual de cada projeto (versão na última coluna).
| Framework | Desligar páginas de erro detalhadas | Onde ficam os segredos, e o cuidado | Configuração muitas vezes esquecida | Docs conferidos |
|---|---|---|---|---|
| WordPress | WP_DEBUG como false no wp-config.php (false por padrão) | Credenciais do banco no wp-config.php; nunca deixe cópias em diretórios públicos | DISALLOW_FILE_EDIT para bloquear a edição de arquivos pelo painel; apague plugins sem uso | Advanced Administration Handbook |
| Laravel | APP_DEBUG=false no .env | Nunca comite o .env (um .env.encrypted criptografado pode) | Depois de config:cache, env() fora dos arquivos de configuração não retorna nada | 13.x |
| Next.js | Rode next build e depois next start; nunca exponha o servidor de desenvolvimento | Variáveis NEXT_PUBLIC_ são embutidas no JavaScript do navegador | Um segredo com o prefixo NEXT_PUBLIC_ | 16.x |
| Spring Boot | Mantenha stack traces fora das respostas de erro (deixe o padrão) | Passe valores por variáveis de ambiente, não por configuração hardcoded | O Actuator expõe só health via HTTP por padrão; nunca defina management.endpoints.web.exposure.include=* | 4.1 |
| Django | DEBUG = False | Carregue a SECRET_KEY de uma variável de ambiente ou de um arquivo; mantenha-a fora do controle de versão | Defina ALLOWED_HOSTS; rode manage.py check --deploy | 6.1 |
| Ruby on Rails | Use a configuração do ambiente de produção (config/environments/production.rb) | config/credentials.yml.enc mais config/master.key; nunca comite o master.key | config.force_ssl = true para forçar HTTPS | 8.1 |
| Express | NODE_ENV=production remove os stack traces da resposta de erro padrão | Passe por variáveis de ambiente, não pelo código | helmet para cabeçalhos seguros; app.disable('x-powered-by') | Guia oficial atual |
| ASP.NET Core | A Developer Exception Page só fica ligada no ambiente Development (padrão do template atual) | User secrets são para desenvolvimento; em produção use variáveis de ambiente ou um key vault | Nunca rode produção com ASPNETCORE_ENVIRONMENT definido como Development | 10.0 |
Casos reais: a maioria dos incidentes veio de atualizações puladas e de configurações de produção, não de bugs do núcleo
O padrão que se destaca não é a falha do framework em si, mas uma correção que existia e não foi aplicada, ou uma configuração de desenvolvimento deixada em produção.
- Equifax (2017): a correção da falha no Apache Struts (CVE-2017-5638) foi lançada no dia da divulgação, mas não foi aplicada num sistema público, e dados pessoais de cerca de 147 milhões de pessoas vazaram (→ o vazamento da Equifax).
- Log4Shell (2021): uma falha numa biblioteca de log do Java. Muitas organizações a tinham embutida por meio de outros componentes e não conseguiam dizer se a usavam (→ Log4Shell).
- Casos de agentes de IA (2026): quando agentes de IA de pesquisa chegaram a sites reais, credenciais foram lidas de uma página de debug exposta, e os sites não perceberam (→ agentes de IA chegando a sites reais).
No OWASP Top 10 (2025), o número um é a quebra de controle de acesso, o número dois é a configuração de segurança incorreta e o número três são as falhas na cadeia de suprimentos de software (problemas nos componentes de que você depende). Todos acontecem em qualquer framework.
Como verificar o seu próprio site
Só faça estas verificações em sites que você administra.
Abra uma URL inexistente e olhe a página de erro
Use os próprios comandos de verificação do framework
python manage.py check --deploy; o Laravel mostra o modo debug com php artisan about --only=environment. No Spring Boot, verifique management.endpoints.web.exposure.include na sua configuração.Varra as dependências e o que é visível de fora
npm audit para npm, composer audit para o Composer ou osv-scanner para tudo (pelo navegador: o scanner de vulnerabilidades de dependências). Para o que quem está de fora consegue ver, a verificação de cabeçalhos de segurança mostra os cabeçalhos ausentes, e a auditoria completa de segurança do site verifica de uma vez a exposição de .env e .git, os certificados e as flags de cookies.Erros comuns e como corrigir
| Erro comum | O que acontece | Correção |
|---|---|---|
Dar o prefixo NEXT_PUBLIC_ a uma chave de API secreta | A chave é embutida no JavaScript do navegador, onde qualquer pessoa pode lê-la | Tire o prefixo, use-a só no servidor e revogue a chave vazada no emissor |
| Expor todos os endpoints de monitoramento (ex.: Spring Boot Actuator) | Valores de configuração e conteúdo da memória podem ser lidos de fora | Exponha só health e similares; deixe o resto atrás de autenticação |
| Desativar plugins sem uso, mas deixá-los instalados | Os arquivos continuam no servidor e deixam de receber atualizações | Apague o que você não usa |
| Ler um aviso de atualização sem confirmar que foi aplicada | A brecha continua aberta mesmo existindo correção (o padrão da Equifax) | Verifique a versão depois de atualizar e rode varreduras de dependências periodicamente |
A visão deste site: os incidentes vêm de como o framework é operado, não do framework em si
Discutir «este framework é seguro/perigoso» raramente ajuda. A maioria dos incidentes reais não vem de um bug do núcleo, mas do uso — atualizações negligenciadas, segredos expostos, autorização ausente, padrões perigosos. Este site roda sobre o próprio Next.js, e nossa defesa principal não tem nada de especial: monitorar CVEs de dependências, manter segredos fora do código e dos diretórios públicos, autenticação forte, backups recuperáveis. Cada capítulo de framework aplica esse básico àquela tecnologia específica.
Primeiro, cubra o básico compartilhado
Antes de mergulhar em um capítulo de framework, é eficiente estabelecer primeiro o que funciona em todas as tecnologias.
- Início: a lista de verificação da base de segurança (contas de administrador, segredos, correção, detecção, recuperação)
- Prática: o manual de resposta a vulnerabilidades · monitorar CVEs de dependências (osv-scanner)
- Segredos: mantenha segredos fora dos diretórios públicos
Fontes
- WordPress Advanced Administration Handbook, "Hardening WordPress" e "Debugging in WordPress" — developer.wordpress.org
- Laravel 13.x, "Configuration" (Environment File Security / Debug Mode) — laravel.com
- Next.js, "How to use environment variables in Next.js" (16.x) — nextjs.org
- Spring Boot 4.1, "Endpoints" (exposição do Actuator) — docs.spring.io
- Django 6.1, "Deployment checklist" — docs.djangoproject.com
- Ruby on Rails Guides, "Securing Rails Applications" (8.1) — guides.rubyonrails.org
- Express, "Production Best Practices: Security" e "Error Handling" — expressjs.com
- Microsoft Learn, "Handle errors in ASP.NET Core" (10.0) — learn.microsoft.com
- OWASP Top 10:2025 — top10.owasp.org
Leia a seguir
- Guias: segurança do WordPress · segurança do Laravel
- Básico: a lista de verificação da base de segurança (compartilhada por todos os frameworks)
- Glossário: o que é um CVE (a unidade para rastrear as falhas conhecidas de um framework)