Importante

Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!

1
resposta

Até quando vale a pena detalhar o tratamento de erros

Meu questionamento é o seguinte, em um ambiente real até que ponto vale apena se preocupara em detalhar os tratamentos de erros, visto que um hacker pode usar os tratamentos que eu mesmo dei para montar uma superficíe de ataque

1 resposta

Oii, João! Tudo bem?

Passando aqui para complementar o excelente questionamento que você levantou. Essa é uma preocupação muito válida e que diferencia profissionais júnior de profissionais sênior focados em segurança.

Em cenários reais de mercado, adotamos a regra de ouro: mensagens amigáveis para quem consome a API, mas detalhes técnicos restritos aos logs internos.

Como equilibrar segurança e usabilidade na prática:

  • O que o cliente vê (Front-end): Mensagens padronizadas e genéricas o suficiente para não entregar a arquitetura do sistema. Retornos como "Dados inválidos" ou "Recurso não encontrado" ajudam a pessoa usuária a corrigir um erro de digitação sem dar pistas sobre qual banco de dados, versão ou ORM está rodando por trás.
  • O que o servidor registra (Logs): É aqui que o detalhamento deve acontecer. No bloco catch, o erro original completo, junto com o stack trace, deve ser enviado para uma ferramenta de monitoramento ou salvo em arquivos de log do servidor. Dessa forma, a equipe de engenharia consegue debugar o problema rapidamente sem expor nenhuma vulnerabilidade para a internet.

Protegendo a superfície de ataque:

Validações como a verificação do CastError apenas confirmam que o formato do parâmetro não atende ao esperado pelo Mongoose. Por si só, isso não representa uma brecha grave, mas para blindar a API contra explorações maliciosas, combinamos essa estratégia com:

  1. Uso de Middlewares de erro: Centralizar o tratamento para evitar vazamentos acidentais de exceções brutas nas respostas HTTP.
  2. Bibliotecas de segurança: Ocultar cabeçalhos que revelam a stack tecnológica da aplicação.
  3. Validação e sanitização: Garantir que entradas inesperadas sejam barradas logo na entrada da requisição.

O detalhamento das mensagens serve para guiar o uso legítimo da aplicação, enquanto a segurança de infraestrutura fica totalmente garantida mantendo os detalhes técnicos confinados no servidor.

Você já passou por alguma situação em projetos reais onde precisou ajustar o nível de detalhe de um erro para evitar expor dados sensíveis?

Alura Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!