Scanner de painéis expostos

Como funciona esta verificação

O Scanaris pede uma lista de rotas que correspondem a painéis e ferramentas de depuração que nunca deviam responder em produção, e confirma que a resposta é a real dessa ferramenta e não a página genérica do teu site. As rotas e a sua severidade: /actuator/health do Spring Boot (alta), /actuator/env e /actuator/heapdump (críticas: variáveis de ambiente e um despejo de memória), /telescope/requests do Laravel Telescope (alta), /_ignition/health-check do Laravel Ignition em modo debug (crítica, porque versões vulneráveis permitiam executar código), /_profiler do Symfony (alta), /.vscode/sftp.json com credenciais de deploy (crítica), /server-status do Apache (média) e /phpmyadmin/ (alta).

Porque importa

Estas ferramentas existem para mostrar as entranhas da aplicação a quem a desenvolve: configuração, variáveis de ambiente com palavras-passe, consultas recentes com os seus parâmetros, rastos de erro completos, o conteúdo da memória do processo. Em desenvolvimento são valiosíssimas; em produção, abertas à internet, são uma porta com a chave na fechadura. Um /actuator/env acessível costuma incluir a string de ligação à base de dados. Um phpMyAdmin público é um ponto de entrada para testar palavras-passe contra a tua base de dados 24 horas por dia.

Porque acontece

Porque a mesma configuração serve para desenvolver e para produção. O modo debug do Laravel (APP_DEBUG=true), os endpoints do Actuator expostos por defeito em versões antigas do Spring, o profiler do Symfony com APP_ENV=dev, um phpMyAdmin instalado "para ver a base de dados um momento" e nunca retirado. As ferramentas de IA que geram o projeto raramente distinguem ambientes, e o deploy herda a configuração de desenvolvimento.

Como corrigir

• Laravel: APP_DEBUG=false e APP_ENV=production no .env de produção. Telescope só em ambientes locais (TELESCOPE_ENABLED=false ou o gate de autorização). Atualiza o Ignition para uma versão sem a vulnerabilidade.
• Spring Boot: management.endpoints.web.exposure.include=health no máximo, sem env nem heapdump, e com segurança à frente de /actuator. Melhor ainda, expor o actuator numa porta de gestão diferente que não saia para a internet.
• Symfony: APP_ENV=prod e APP_DEBUG=0; o profiler só se regista em dev.
• phpMyAdmin: desinstala-o do servidor público. Se precisas dele, acede por túnel SSH ou restringe-o por IP e com autenticação adicional.
• Apache server-status: Require ip 127.0.0.1 na diretiva Location /server-status, ou desativa o módulo.
• Ficheiros de editor como .vscode/sftp.json: nunca devem ser publicados. Acrescenta .vscode/ ao .gitignore e, se esteve publicado, muda a palavra-passe que contém.

Confirma que está corrigido

for p in actuator/health actuator/env telescope/requests _ignition/health-check _profiler .vscode/sftp.json server-status phpmyadmin/; do
  printf "%-26s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://oteudominio.com/$p"
done

O esperado é 404, 403 ou 401 em todos. Um 200 só é aceitável se o que devolve é a tua página genérica e não a ferramenta.

Perguntas frequentes

O meu painel pede palavra-passe. Continua a ser um achado?

O Scanaris verifica o conteúdo, por isso um painel protegido com autenticação que devolve 401 não é marcado. Ainda assim, um phpMyAdmin com login é um alvo de força bruta; melhor fora da internet.

E o /actuator/health? Só diz "UP".

Confirma que tecnologia usas e que versão do Spring, e costuma indicar que os outros endpoints também estão expostos. Se precisas de um health check público para o teu balanceador, cria uma rota própria mínima em vez de abrir o actuator.

Uso Next.js ou Nuxt. Isto aplica-se a mim?

Estas rotas concretas não, mas o princípio sim: as rotas de API de depuração ou de seed (/api/debug, /api/seed) que a IA cria para testar têm de desaparecer antes do deploy.