← todos os artigos

.NET

O que eu faço para tornar uma aplicação .NET mais segura

Segurança não é só authentication. Higiene de version control, secrets, validação de JWT, RBAC, HTTPS, monitoramento, confiança em dependencies, e revisar todo pedaço de código gerado por LLM antes de rodar.

O que eu faço para tornar uma aplicação .NET mais segura

Segurança de aplicação não é só sobre adicionar authentication. Também envolve proteger o código, a infraestrutura, os dados, as dependencies, e o processo de desenvolvimento.

Use version control direito

O Git ajuda a rastrear mudanças, revisar código, e se recuperar de erros.

Porém, arquivos sensíveis nunca deveriam ser commitados. Uso .gitignore para excluir configuração local, secrets, e arquivos gerados.

appsettings.Development.json
.env
*.user

Repositórios também deveriam usar pull requests e code reviews antes de mudanças importantes serem mescladas.

Nunca hardcode secrets

Senhas, connection strings, API keys, e chaves de assinatura de JWT não deveriam ser armazenadas diretamente no código-fonte.

var connectionString =
    builder.Configuration.GetConnectionString("DefaultConnection");

Durante o desenvolvimento, uso .NET User Secrets. No Azure, secrets podem ser armazenados no Azure Key Vault ou fornecidos através de configuração segura de ambiente.

Proteja os endpoints da API

Endpoints deveriam ser protegidos usando authentication e authorization.

[Authorize]
[HttpGet("profile")]
public IActionResult GetProfile()
{
    return Ok();
}

Para operações restritas, uso roles ou authorization policies:

[Authorize(Roles = "Admin")]

Endpoints públicos deveriam ser intencionais. Operações sensíveis nunca deveriam depender só do frontend escondendo um botão.

Configure o JWT com cuidado

JWT pode ser usado para autenticar requests, mas tokens precisam ser validados corretamente.

A API deveria validar o issuer, a audience, a signature, e o tempo de expiração.

Tokens deveriam ter um tempo de vida razoável, e as chaves de assinatura precisam ser protegidas. Payloads de JWT são codificados, não criptografados, então senhas ou informações sensíveis nunca deveriam ser colocadas dentro deles.

Siga RBAC e least privilege

O AZ-900 me apresentou ao Role-Based Access Control do Azure. RBAC define quem pode acessar um resource e quais ações pode executar.

O mesmo princípio se aplica dentro de uma aplicação. Usuários, serviços, e contas de database deveriam receber só as permissões de que precisam. Uma conta de database de uma aplicação não deveria automaticamente ter acesso de administrador a todo o database server.

Use HTTPS

HTTPS protege a comunicação entre clients e a API.

app.UseHttpsRedirection();

Aplicações de produção deveriam usar certificados TLS válidos e evitar expor endpoints sensíveis através de HTTP não criptografado.

Monitore a aplicação

Logs ajudam a identificar erros, atividade suspeita, e problemas de performance. Ferramentas como Grafana conseguem exibir dashboards usando métricas coletadas da aplicação e da infraestrutura.

Sinais úteis incluem tentativas de login falhas, taxas de erro altas, volume incomum de requests, endpoints lentos, e uso de CPU ou memória. Logs nunca deveriam conter senhas, access tokens, ou dados sensíveis completos.

Use dependencies confiáveis e atualizadas

Toda dependency adiciona código que eu não escrevi mas do qual minha aplicação ainda depende. Antes de instalar um pacote, checo se ele é mantido ativamente, se vem de uma fonte confiável, se tem vulnerabilidades conhecidas, e se a aplicação realmente precisa dele.

Pacotes deveriam ser atualizados com cuidado, testados, e revisados em vez de instalados automaticamente sem entender o impacto.

Revise código gerado por LLM

LLMs conseguem ajudar a gerar código, configuração, e arquivos de infraestrutura, mas o output deles nunca deveria ser aceito cegamente. Eu sempre revejo todo comando antes de rodar, todo pacote sendo instalado, mudanças de authentication e authorization, migrations de database, secrets e configuração, arquivos de Docker e deployment, e qualquer código que deleta ou modifica dados.

O desenvolvedor continua responsável pelo código final.

Checklist final

Use version control e code reviews.
Nunca hardcode secrets.
Proteja endpoints sensíveis.
Valide tokens JWT corretamente.
Aplique RBAC e least privilege.
Use HTTPS.
Monitore logs e métricas.
Use dependencies confiáveis.
Revise todo código gerado por LLM.

Segurança não é uma feature adicionada no final. Deveria fazer parte de todo estágio do desenvolvimento.