Por framework
Segurança do ASP.NET Core — erros em produção, segredos e autorização
O ASP.NET Core é sólido, mas os incidentes vêm das configurações: erros detalhados expostos em produção, segredos fixos em appsettings e [Authorize] ausente. Oculte erros em produção, carregue segredos de fora da config, autorize explicitamente. Defensivo, sem passos de ataque.
Para: qualquer pessoa que opere um app ou API no ASP.NET Core. Sem passos de ataque aqui — só manter a base sólida funcionando enquanto fecha as lacunas que as configurações abrem. Para o panorama completo, veja o hub de segurança por framework.
As três grandes armadilhas (elas se abrem nas configurações)
Os mecanismos do ASP.NET Core são excelentes, mas estas três são suas para proteger nas configurações e no código.
① Erros detalhados em produção
A Developer Exception Page etc. vaza internos. Extraídos via erros deliberados.
② Segredos em appsettings
Strings de conexão/chaves fixas. Vazam por commit acidental ou exposição.
③ [Authorize] ausente
Esqueça-o e qualquer um o alcança. Sem verificação de proprietário também.
Fique atento também a desserialização insegura (BinaryFormatter, etc.), over-posting no model binding e CVEs de dependências NuGet sem correção.
Como fechá-las (3 passos)
Oculte erros detalhados em produção
Carregue segredos de fora da config
Torne a autorização explícita e corte os caminhos de entrada perigosos
[Authorize] e verificações de proprietário aos endpoints (incline para negar por padrão). Limite o over-posting com DTOs ou [Bind], e não desserialize dados não confiáveis com formatos inseguros. Mantenha as dependências NuGet com CVEs monitorados + corrigidos rápido (→ o que é IDOR).Comum (perigoso)
- Developer Exception Page exposta em produção
- segredos fixos em
appsettings.json [Authorize]esquecido, sem verificação de proprietário- modelos aceitando todos os campos (over-posting)
Correto
- produção oculta erros detalhados
- segredos de User Secrets/env/Key Vault
- autorização explícita (negação por padrão, verificações de proprietário)
- DTOs/[Bind] para limitar o binding
A visão deste site: mesmo sobre uma base sólida, as configurações e a autorização são sua responsabilidade
O ASP.NET Core tem mecanismos sólidos para autenticação, autorização e proteção de dados, mas as configurações de produção e a aplicação da autorização são coisas que você precisa acertar por ambiente e por endpoint. Este site roda sobre outra stack, mas o princípio é o mesmo: não vaze internos em produção, mantenha segredos fora da config, escreva sempre autorização nos pontos de entrada públicos e monitore as dependências por CVEs. Uma base sólida só compensa com configurações corretas e autorização explícita.
Leia a seguir
- Hub: segurança por framework · segurança do Spring Boot (também corporativo, forma de dependência/autorização parecida)
- Segredos: mantenha segredos fora dos diretórios públicos · Prática: o manual de resposta a vulnerabilidades
- Glossário: o que é IDOR · o que é RCE
FAQ
QO ASP.NET Core é seguro?
O ASP.NET Core é uma base madura e sólida, com mecanismos fortes para autenticação, autorização e Data Protection. Usado corretamente é poderoso, mas os incidentes vêm não do núcleo, e sim das configurações. Expor erros detalhados em produção, fixar segredos em appsettings e esquecer atributos de autorização recorrem menos como problemas específicos do framework e mais como problemas de configuração/operação.
QOnde os segredos (strings de conexão, chaves de API) devem ficar?
A regra é: não fixos em appsettings.json. Em desenvolvimento use User Secrets; em produção carregue de variáveis de ambiente ou de um gerenciador de segredos na nuvem (por exemplo, Key Vault). O appsettings.json tende a acabar no repositório e vaza facilmente por um diretório público ou por um commit acidental. Se um vazar, rotacione a string de conexão ou a chave prontamente.
QComo evito esquecer atributos de autorização?
Esqueça o [Authorize] em um controller ou endpoint e qualquer pessoa consegue alcançá-lo sem autenticação. Incline o padrão para 'negar' (uma política de fallback que rejeita requisições não autenticadas), torne as permissões explícitas com autorização baseada em role/policy e escreva verificações de proprietário do recurso. Não pare em 'logado = permitido' — verifique também o proprietário do alvo.