# Cybersegurança para Desenvolvedores: o Básico

> Published 2026-09-28T11:55:56.996Z on https://www.crazystack.com.br/pt/p/cyberseguranca-para-desenvolvedores-o-basico/
> Source video: https://www.youtube.com/watch?v=JmjlZE-lM74

Cybersegurança para desenvolvedores começa em três frentes: validar inputs, proteger APIs e criptografar dados. Veja as ferramentas e os erros que custam caro.

## O que é cybersegurança para desenvolvedores, no mínimo?

Cybersegurança para desenvolvedores significa validar todo input de usuário, autenticar APIs com token e refresh token, criptografar dados sensíveis e manter uma cultura de segurança no time. Esses quatro pontos cobrem a maior parte das falhas que permitem invasões em aplicações web comuns.

A lógica é simples. Se você constrói uma tela de login com campos de e-mail e senha, esses valores vão direto para o banco de dados. Qualquer campo que aceita entrada do usuário é um acesso ao banco e, portanto, um candidato a ataque. Tratar isso como regra de construção, e não como etapa final, é o que caracteriza uma cultura de segurança.

Essa cultura inclui hábitos do dia a dia: exigir 2FA nas contas da empresa, redefinir senhas de e-mail em suspeita de vazamento e trocar credenciais imediatamente quando um arquivo de variáveis de ambiente aparece exposto no GitHub. Quando um atacante entra, o tempo de reação define o tamanho do prejuízo.

## SQL injection: por que todo input precisa de validação?

SQL injection acontece quando o atacante insere comandos SQL em um campo de formulário e o banco executa esses comandos. É um dos ataques mais antigos da web e continua viável sempre que o input não é tratado. A OWASP documenta o ataque e as formas de prevenção em [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection).

Na prática, o erro típico é montar a consulta concatenando o que o usuário digitou. O correto é usar consultas parametrizadas e validar o tipo e o formato de cada campo antes de tocar o banco. Isso vale tanto para o formulário público quanto para telas internas do painel administrativo.

Uma segunda camada do mesmo problema é o output. No caso relatado no vídeo, a descrição de um evento era renderizada na página inicial sem sanitização, e o texto continha um script que redirecionava visitantes para um site de fraude. Validar entrada e escapar saída são tarefas distintas, e as duas precisam existir.

Ferramentas de inteligência artificial ajudam nessa revisão. O [ChatGPT](https://chatgpt.com), assistente da OpenAI, e o [Claude Code](https://www.anthropic.com/claude-code), ferramenta de codificação agêntica da Anthropic que roda no terminal, podem auditar código em busca de inputs expostos e consultas mal construídas. Ainda assim, a revisão final continua sendo responsabilidade de quem faz deploy.

## APIs públicas: token e refresh token são obrigatórios?

Sim. Toda consulta de API que toca o banco de dados precisa de autenticação por token, e o token deve ser renovável via refresh token. Armazenar um token fixo e reutilizá-lo indefinidamente transforma um vazamento único em acesso permanente ao sistema.

O risco cresce quando API e segredos ficam expostos juntos. Plataformas de criação de aplicativos com inteligência artificial aceleraram o deploy de projetos sem revisão, e casos públicos de variáveis de ambiente expostas se tornaram recorrentes. A [Vercel](https://vercel.com), plataforma de hospedagem e deploy por trás do Next.js, é frequentemente citada nesses contextos porque concentra muitos deploys rápidos de pequenos times.

Com usuário e senha em mãos, o atacante não precisa quebrar nada: ele entra pelo caminho legítimo e escala privilégios por dentro. Autenticação forte na porta de entrada e checagem de permissão em cada operação reduzem esse dano.

## Engenharia social: qual é o elo mais fraco do sistema?

O elo mais fraco costuma ser a pessoa, não o código. Engenharia social é a técnica de enganar alguém para obter credenciais legítimas. Um caso conhecido no Brasil envolveu um atacante que se passou pelo suporte de uma plataforma de criação de apps com IA, pediu usuário e senha e entrou no sistema como usuário comum.

Depois de autenticado, o invasor escalou privilégios e acessou dados internos. Nenhuma falha de código sofisticada foi necessária. É por isso que treinamento de time e verificação de identidade em pedidos de suporte fazem parte da segurança tanto quanto firewalls.

O custo de falhar também é financeiro e reputacional. Empresas hackeadas perdem clientes, e negócios de capital aberto tendem a ver queda forte nas ações após incidentes públicos. No setor de criptoativos, uma corretora invadida pode comprometer diretamente o dinheiro dos usuários.

## Criptografia: o que nunca pode ficar em texto plano?

Senhas, credenciais de banco e dados de cartão nunca devem ficar em texto plano. Senhas precisam de hash com biblioteca dedicada como [bcrypt](https://www.openwall.com/crypt/), que aplica custo computacional deliberado para dificultar quebra. Dados de cartão de crédito, na regra geral, não devem ser armazenados no seu banco; quando o negócio exige, use um provedor de tokenização de pagamentos.

O vídeo traz dois exemplos reais de descuido. Em uma empresa de ingressos hackeada, o atacante usou um usuário comum para injetar conteúdo malicioso na página inicial. Em outra companhia, comprada por R$ 7 milhões, senhas de banco de dados estavam escritas diretamente no código-fonte. Um único vazamento do repositório entregaria o sistema inteiro.

Segredos no código têm solução simples: variáveis de ambiente gerenciadas fora do repositório, com rotação de credenciais quando há suspeita de exposição. Essa prática custa minutos e evita o cenário em que um acesso isolado derruba todo o negócio.

## Quais ferramentas o dev deve instalar para estudar ataques?

Para começar em segurança ofensiva, duas ferramentas cobrem o essencial: o [Kali Linux](https://www.kali.org/), distribuição Linux voltada a testes de segurança e ataque, e o [Burp Suite](https://portswigger.net/burp), da PortSwigger, que intercepta e manipula requisições HTTP. O Burp Suite tem versão gratuita usada por boa parte dos profissionais de teste de intrusão.

O fluxo básico de estudo é direto:

1. Instale o Kali Linux em uma máquina virtual ou máquina dedicada, nunca no computador do dia a dia.

2. Abra o Burp Suite como proxy e navegue em uma aplicação que você mesmo controla ou que esteja em ambiente de laboratório.

3. Interceptar requisições e observar como o servidor responde quando você altera parâmetros, cookies e cabeçalhos.

4. Reproduza o mesmo raciocínio nos seus próprios projetos: cada input que o Burp consegue manipular é um ponto que o seu código precisa validar.

Testes ofensivos só são legais em sistemas próprios ou com autorização expressa do dono. Plataformas de bug bounty existem exatamente para formalizar essa autorização em aplicações de terceiros.

## Perguntas frequentes

- **Dev júnior precisa saber cybersegurança antes do primeiro emprego?** Não é pré-requisito para a contratação, mas validar inputs e proteger APIs é esperado desde o início. O que consolida esse conhecimento é a prática no trabalho, porque faculdade e cursos raramente acompanham a velocidade das mudanças.

- **Burp Suite é gratuito mesmo?** Sim, existe uma versão gratuita no site da PortSwigger que cobre interceptação de requisições, o uso mais comum em estudos. Versões pagas adicionam automação e recursos avançados de varredura, mas não são necessárias para aprender.

- **Kali Linux serve para defesa ou só para ataque?** O Kali reúne ferramentas dos dois lados, mas é mais conhecido pelo uso ofensivo em testes de intrusão. Entender como o ataque funciona é o que permite construir a defesa correspondente no seu código.

- **Posso guardar cartão de crédito no meu banco de dados?** Na regra geral, não. Use um gateway de pagamento com tokenização, que armazena o dado sensível e devolve a você apenas um token sem valor fora daquele contexto.

- **A inteligência artificial resolve a segurança do meu código?** Ferramentas como o Claude Code ajudam a auditar e apontar vulnerabilidades, mas a responsabilidade pela revisão continua no time de desenvolvimento. Código gerado por IA também pode sair com segredos expostos se ninguém conferir o deploy.

[Source video](https://www.youtube.com/watch?v=JmjlZE-lM74)