Existe uma expressão que resume bem o dia em que uma aplicação é invadida: ser pego de calça curta. É aquele momento em que o problema já aconteceu e não dá mais pra fingir que estava tudo sob controle. Foi com esse espírito — direto e sem susto desnecessário — que Danrley Pereira e Pedro Druck subiram ao palco da trilha DW Corp na Campus Party Brasil 2025 (CPBR17), em Brasília, para falar de segurança web na prática.
Este recap tenta manter a mesma pegada da palestra: nada de jargão assustador, só o essencial que todo desenvolvedor deveria saber antes de colocar algo no ar.
Segurança não é luxo de sênior
Uma ideia atravessou toda a sessão: segurança não é uma etapa que você liga no fim do projeto, nem tarefa exclusiva de gente sênior. Ela começa na primeira linha de código. Quanto mais cedo você pensa em como sua aplicação pode ser abusada, mais barato e mais simples é se proteger.
A boa notícia é que a maioria dos ataques do mundo real não é sofisticada. São os mesmos erros repetidos, e já existe um mapa deles.
OWASP Top 10 em linguagem de gente
Esse mapa é o OWASP Top 10 — uma lista mantida pela comunidade com as categorias de falha mais comuns em aplicações web. Pense nela como um checklist do que costuma dar errado: falhas de controle de acesso, dados sensíveis expostos, injeções, más configurações de segurança, componentes desatualizados, entre outros.
O valor da lista não é decorá-la, e sim usá-la como lente. Antes de subir uma feature, vale perguntar: onde essa mudança toca em cada um desses riscos? Foi assim que Danrley e Pedro conduziram a plateia — pegando itens do Top 10 e mostrando como eles aparecem no código do dia a dia.
Injeções: o clássico que ainda derruba sistemas
Injeção é quando dados enviados pelo usuário são interpretados como comando. O exemplo clássico é SQL injection: um campo de busca inocente que, mal tratado, permite reescrever a consulta ao banco. Mas o princípio vale para qualquer lugar onde entrada vira execução — comandos, HTML, consultas.
A defesa mostrada na prática foi simples e consistente: nunca confie na entrada do usuário. No back-end Flask, isso significa usar consultas parametrizadas em vez de concatenar strings de SQL, e validar tudo que chega. No front React, significa não injetar HTML cru vindo do usuário e deixar o próprio framework escapar o conteúdo. A regra de ouro: trate todo dado externo como suspeito até prova em contrário.
Controle de acesso: quem pode o quê
Outro campeão de incidentes é o controle de acesso quebrado — quando o sistema esquece de checar se aquele usuário realmente pode fazer aquela ação. É o caso clássico de trocar um id na URL e acabar vendo o pedido de outra pessoa.
O ponto levantado no palco foi que autenticação e autorização são coisas diferentes. Autenticar é saber quem é o usuário; autorizar é decidir o que ele pode. Esconder um botão no front não é segurança — a verificação de permissão precisa acontecer sempre no servidor, a cada requisição.
OAuth2 e JWT sem misticismo
A parte que mais gerou perguntas foi sobre login. OAuth2 e JWT costumam soar místicos, mas a dupla desmontou isso com analogias simples.
OAuth2 é um protocolo de autorização: em vez de dar sua senha para cada aplicação, você autoriza que ela receba um "cartão de acesso" com permissões limitadas. É o que acontece quando você faz "entrar com o Google".
JWT (JSON Web Token) é o formato desse cartão: um token assinado que carrega informações sobre quem você é e o que pode. Como é assinado, o servidor consegue verificar se foi adulterado. No exemplo com React e Flask, o front guarda o token e o envia a cada requisição; o back em Flask valida a assinatura e a expiração antes de liberar qualquer coisa. Os cuidados destacados: não colocar dados sensíveis dentro do token, definir expiração curta e sempre validar no servidor — nunca confiar apenas no que o cliente diz.
O que levar pra casa
O recado final de Danrley e Pedro foi tranquilizador: você não precisa ser um especialista em segurança para elevar muito o nível da sua aplicação. Precisa de alguns hábitos — desconfiar da entrada do usuário, checar permissões no servidor, entender o que seus tokens carregam e manter as dependências atualizadas.
Segurança é menos sobre paranoia e mais sobre cuidado constante. E cuidar disso cedo é a melhor forma de nunca ser pego de calça curta.
