Segurança para desenvolvedores: protegendo aplicação, dados e infraestrutura

Por que segurança é responsabilidade do desenvolvedor

Segurança não é papel exclusivo do time de infra ou do CISO

A maioria das vulnerabilidades exploradas em produção não vem de falhas de infraestrutura, mas de código mal escrito: queries sem parametrização, validações ausentes, segredos hardcoded e lógica de autorização quebrada. Desenvolvedores que entendem as ameaças concretas escrevem código intrinsecamente mais seguro, reduzindo a superfície de ataque antes que qualquer ferramenta de análise precisar agir. O custo de corrigir uma vulnerabilidade em produção é estimado pela NIST em até 30 vezes maior do que durante o desenvolvimento. Incorporar segurança no ciclo de vida do software — a filosofia Shift Left Security — é tanto uma prática de qualidade quanto uma responsabilidade profissional de qualquer desenvolvedor que coloca código em produção.

OWASP Top 10 — as vulnerabilidades mais críticas

A lista que define o mínimo que todo desenvolvedor precisa conhecer

A OWASP (Open Worldwide Application Security Project) publica periodicamente a lista das 10 categorias de vulnerabilidades mais críticas em aplicações web, baseada em dados reais de incidentes e contribuições da comunidade global de segurança. A edição atual inclui Broken Access Control no topo, seguida de Cryptographic Failures, Injection, Insecure Design e Security Misconfiguration como as categorias mais prevalentes e impactantes. Cada item da lista inclui descrição da vulnerabilidade, exemplos de código vulnerável, impacto potencial e recomendações de mitigação com referências a padrões como CWE e CVSS. Conhecer o OWASP Top 10 não é suficiente para tornar um sistema seguro, mas ignorá-lo é garantia de que as falhas mais comuns e exploradas estarão presentes na aplicação.

Autenticação segura — senhas, hashing, MFA

Como proteger credenciais de usuários contra vazamentos e ataques

Senhas nunca devem ser armazenadas em texto plano ou com hashing simples como MD5 ou SHA-1, que são reversíveis por rainbow tables em segundos. Algoritmos de hashing de senhas como bcrypt, Argon2id e scrypt são projetados especificamente para esse propósito, sendo computacionalmente custosos e incluindo salt automático para impossibilitar ataques de dicionário. A autenticação multifator (MFA) adiciona uma segunda camada de verificação além da senha, como TOTP via aplicativo autenticador ou SMS, tornando comprometimento de senha isolada insuficiente para invadir a conta. Implementações de autenticação devem também incluir proteção contra brute force com rate limiting e bloqueio temporário de conta, além de detecção de login suspeito por IP ou geolocalização.

Autorização — RBAC, ABAC e princípio de menor privilégio

Garantindo que cada usuário acessa apenas o que deve acessar

Autorização controla o que um usuário autenticado pode fazer no sistema, sendo frequentemente mais complexa e mais propensa a erros do que a autenticação em si. Role-Based Access Control (RBAC) associa permissões a papéis e usuários a papéis, simplificando gerenciamento em sistemas onde os perfis de acesso são bem definidos como admin, editor e leitor. Attribute-Based Access Control (ABAC) avalia atributos do usuário, do recurso e do contexto para tomar decisões mais granulares, permitindo políticas como: gerentes podem aprovar despesas do seu próprio departamento até R$10.000. O princípio de menor privilégio determina que cada usuário, serviço ou processo deve ter apenas as permissões estritamente necessárias para sua função, limitando o raio de impacto de uma conta comprometida.

Criptografia em trânsito e em repouso

Protegendo dados sensíveis onde quer que estejam

Criptografia em trânsito usando TLS 1.2 ou 1.3 é obrigatória para toda comunicação de rede que envolva dados sensíveis, protegendo contra interceptação em redes não confiáveis. Certificados TLS devem ser obtidos de Certificate Authorities confiáveis, mantidos atualizados e configurados com cipher suites modernas, desabilitando protocolos obsoletos como SSLv3 e TLS 1.0. Criptografia em repouso protege dados armazenados em banco de dados, filesystems e backups, usando AES-256 para dados simétricos e RSA ou ECDSA para troca de chaves assimétrica. Campos especialmente sensíveis como CPF, número de cartão de crédito e dados de saúde devem ser criptografados individualmente no nível de aplicação, adicionando proteção mesmo se o banco de dados for comprometido com acesso administrativo.

Injeção de código — SQL injection, command injection

A classe de vulnerabilidade mais antiga e ainda mais explorada

SQL injection ocorre quando entrada do usuário é concatenada diretamente em queries SQL sem sanitização, permitindo que um atacante altere a lógica da query para extrair dados, modificar registros ou executar comandos administrativos no banco. A mitigação correta é usar prepared statements com parâmetros em todas as queries, nunca concatenar strings de usuário em SQL, independentemente de validação prévia. Command injection permite ao atacante executar comandos arbitrários no sistema operacional quando entrada do usuário é passada para funções como exec, system ou eval sem sanitização adequada. ORMs modernos como Entity Framework, Hibernate e Prisma parametrizam automaticamente as queries, mas ainda requerem atenção em queries dinâmicas, operações de ordenação e filtros construídos programaticamente.

XSS e CSRF — ataques web clássicos

Protegendo usuários de scripts maliciosos e requisições forjadas

Cross-Site Scripting (XSS) ocorre quando conteúdo não confiável é renderizado como HTML ou JavaScript na página, permitindo que atacantes executem scripts no contexto do navegador da vítima para roubar cookies, tokens ou realizar ações em nome do usuário. A prevenção primária de XSS é encoding de output — converter caracteres especiais como menor-que, maior-que e aspas em entidades HTML ao renderizar dados do usuário — e usar Content Security Policy (CSP) para restringir as origens de scripts permitidas. Cross-Site Request Forgery (CSRF) engana o navegador de um usuário autenticado para enviar requisições não intencionais para um servidor onde está logado, explorando que o navegador envia cookies automaticamente. CSRF tokens — valores aleatórios incluídos em formulários e verificados pelo servidor — são a defesa padrão, complementada pelo atributo SameSite=Strict ou Lax nos cookies de sessão.

Secrets management — não commitar credenciais

Mantendo API keys, senhas e tokens fora do controle de versão

Credenciais commitadas em repositórios Git são uma das causas mais comuns de incidentes de segurança, pois o histórico do Git preserva o segredo mesmo após commits de remoção e repositórios públicos são escaneados automaticamente por ferramentas maliciosas. Variáveis de ambiente injetadas pelo ambiente de execução — não hardcoded no código — são a solução mínima, mas não suficiente para ambientes complexos com muitos segredos. Secret managers como AWS Secrets Manager, HashiCorp Vault e Azure Key Vault centralizam armazenamento, controlam acesso com políticas granulares, auditam uso e suportam rotação automática. Ferramentas de scanning como git-secrets, TruffleHog e Gitleaks devem ser integradas ao pipeline de CI para detectar credenciais acidentalmente adicionadas antes de chegarem ao repositório remoto.

Dependency scanning — vulnerabilidades em bibliotecas

O código de terceiros que você usa também pode ser seu ponto fraco

Aplicações modernas dependem de dezenas a centenas de bibliotecas de terceiros, cada uma podendo conter vulnerabilidades conhecidas catalogadas em bancos como o CVE (Common Vulnerabilities and Exposures) e o NVD (National Vulnerability Database). Ferramentas como npm audit, OWASP Dependency-Check, Snyk e Dependabot escaneiam as dependências do projeto e alertam sobre versões com vulnerabilidades conhecidas, informando criticidade e disponibilidade de fix. A política de atualização de dependências deve equilibrar estabilidade com segurança — dependências com vulnerabilidades de severidade alta ou crítica devem ser atualizadas com prioridade, independentemente de breaking changes. Software Composition Analysis (SCA) como parte do pipeline de CI garante que nenhum artefato com vulnerabilidades conhecidas de alta criticidade seja promovido para produção sem revisão consciente.

Conclusão — segurança como parte do desenvolvimento, não um afterthought

Incorporar segurança desde o design é mais barato e mais eficaz

Segurança não pode ser adicionada como uma camada sobre uma aplicação mal projetada — ela precisa ser considerada em cada decisão de arquitetura, cada linha de código e cada configuração de deploy. Conhecer as ameaças concretas, aplicar defesas em profundidade e revisar regularmente a postura de segurança são práticas que diferenciam sistemas confiáveis de sistemas que aguardam o próximo incidente. Continue em: Fundamentos obrigatórios antes de produção.