Navegue por tópicos
O que e segurança no front-end (e por que você precisa se preocupar)?
Se você já ouviu alguém dizer que segurança é coisa do back-end, saiba que essa ideia é perigosa. E cada vez mais fora da realidade.
Imagine a seguinte situação: você passou semanas construindo uma aplicação sólida, com UX cuidadosa, código bem organizado e testes cobrindo os principais fluxos. Num bom dia, você descobre que hackers invadiram o sistema, vazaram dados de clientes e venderam essas informações em mercados clandestinos. O ponto de entrada? O front-end.
Esse cenário, embora fictício, reflete um padrão real e crescente. Segundo dados do FortiGuard Labs — laboratório de inteligência de ameaças da Fortinet — os incidentes de segurança no Brasil praticamente dobraram em 2022 em relação ao ano anterior. E boa parte desse crescimento tem relação direta com a maior adoção de tecnologia e com desenvolvedores que nunca aprenderam a pensar em segurança durante o desenvolvimento.
A boa notícia é: segurança no front-end não é um assunto só para especialistas de nicho. Com os conceitos certos e algumas práticas bem aplicadas, qualquer dev consegue elevar bastante o nível de proteção das suas aplicações.
Os 5 pilares que sustentam uma aplicação segura
Antes de falar em ataques específicos ou ferramentas de defesa, é importante ter um mapa mental de segurança. No livro, o autor organiza tudo em torno de cinco pilares fundamentais. Pense neles como as cinco perguntas que você deveria fazer antes de qualquer decisão técnica.
| Pilar | O que significa na prática |
|---|---|
| Confidencialidade | Dados sensíveis só chegam a quem tem autorização. É a base da confiança do usuário. |
| Integridade | As informações não podem ser alteradas de forma não autorizada. Sem isso, nada garante que os dados são reais. |
| Disponibilidade | A aplicação precisa estar acessível quando o usuário precisar. Um servidor fora do ar no pior momento gera prejuízo e frustra. |
| Autenticidade | Você precisa ter certeza de que o usuário é quem ele diz ser. Sem isso, qualquer um pode se passar por outro. |
| Legalidade | A aplicação precisa estar dentro das regras da LGPD e demais regulações. Ignorar isso gera multas e danos à reputação. |
Para entender como esses pilares funcionam juntos — e como perder qualquer um deles pode ser devastador — veja o caso da NetSafe, um e-commerce fictício criado no livro para ilustrar um ataque real.
O caso NetSafe: quando cinco pilares caem em sequência
Em um ataque coordenado, hackers conseguiram derrubar os cinco pilares um por um:
- Confidencialidade: acessaram o banco e roubaram dados de cartões de crédito.
- Integridade: injetaram scripts que manipulam os preços exibidos na tela.
- Disponibilidade: um ataque DDoS na Black Friday tirou o site do ar por horas.
- Autenticidade: credenciais de admins vazaram, sem nenhum segundo fator de verificação.
- Legalidade: as brechas de privacidade resultam em multas e ações judiciais.
⚠ PONTO DE ATENÇÃO
- Segurança não é responsabilidade só do time de infra ou do back-end.
- O front-end é a primeira superfície de contato com o usuário — e com o atacante.
- Qualquer decisão errada nessa camada pode comprometer todos os cinco pilares ao mesmo tempo.
Os principais ataques e como eles chegam pelo front-end
Conhecer os ataques mais comuns não é só curiosidade técnica. E o primeiro passo para defender a sua aplicação. Cada ataque tem uma lógica própria, explora um ponto especifico e tem contramedidas específicas.
| Sigla | Nome | O que ele faz? |
|---|---|---|
| DoS / DDoS | Negação de Serviço | Inunda o servidor com requisições até derrubá-lo. O front-end sem limites de chamada vira cúmplice. |
| Brute Force | Força Bruta | Adivinha senhas automaticamente. Sem throttle no cliente, o ataque roda direto do console do navegador. |
| XSS | Cross-Site Scripting | Injeta scripts maliciosos. Rouba cookies e tokens. Acontece quando input do usuário vai pro DOM sem filtro. |
| CSRF | Cross-Site Request Forgery | Faz o usuário autenticado executar ações sem querer, aproveitando a sessão ativa. |
| Clickjacking | Sequestro de Clique | Esconde a aplicação em um iframe invisível, capturando cliques que o usuário não pretendia dar. |
| Phishing | Engenharia Social | Explora o fator humano. A tecnologia pode ser perfeita, mas uma pessoa mal informada é o elo mais fraco. |
Um exemplo real: a crianca que derrubou um servidor
Um dos casos mais interessantes do livro envolve uma plataforma educativa para crianças. Uma delas, explorando o console do navegador, descobriu uma função JavaScript que enviava avaliações dos jogos sem nenhum tipo de limite de requisições.
Com um simples loop — algo que ela aprendeu num cursinho de programação — disparou 10.000 requisições ao servidor em questão de segundos. O site foi abaixo.
// Funcao vulnerável exposta no front-end
function enviarAvaliacao(comentario, classificacao) {
axios.post('https://api.exemplo.com/enviar-avaliacao/1234',
{ comentário, classificacao });
}
// O que a criança rodou no console do navegador:
for (let i = 0; i < 10000; i++) {
enviarAvaliacao('Jogo incrivel!', 5);
}A lição aqui não é só sobre o servidor. O front-end também tinha a responsabilidade de limitar essas chamadas. Debounce, throttle e validação de fluxo são defesas que vivem no lado cliente.
XSS: a vulnerabilidade que não sai de moda
Cross-Site Scripting (XSS) é um dos ataques mais antigos da web — e ainda um dos mais explorados. Ele acontece quando a sua aplicação renderiza input do usuário sem nenhum filtro, permitindo que scripts maliciosos rodem no navegador de outras pessoas.
E como deixar uma porta aberta em casa porque você nunca imaginou que alguém ia entrar por ela.
Os tres tipos de XSS
| Tipo | Como funciona | Nível de risco |
|---|---|---|
| XSS Armazenado | Script é salvo no banco e exibido para todos os usuários | Alto – afeta múltiplos usuários |
| XSS Refletido | Payload vem na URL e afeta só quem clica no link malicioso | Médio – requer engenharia social |
| XSS baseado em DOM | Script manipula o DOM diretamente, sem passar pelo servidor | Alto – difícil de detectar |
Como se defender?
A regra de ouro: nunca insira dados do usuário diretamente no DOM. Use textContent no lugar de innerHTML, adote bibliotecas de sanitização como o DOM Purify, e implemente uma Content Security Policy (CSP) como camada adicional.
CSP e SRI: proteções que o navegador já oferece, mas você precisa ativar
Content Security Policy (CSP)
A CSP é uma política enviada no cabeçalho HTTP que diz ao navegador quais origens de conteúdo são confiáveis. Funciona como uma lista de permissões: scripts, estilos e imagens só carregam de domínios que você autorizou explicitamente.
Uma CSP bem configurada bloqueia scripts injetados por XSS — mesmo que o atacante consiga colocar código na página, o navegador não deixa rodar.
# Exemplo de cabecalho CSP
Content-Security-Policy: default-src 'self';
script-src 'self' https://cdn.exemplo.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;Subresource Integrity (SRI)
Quando você carrega uma biblioteca de um CDN externo, você está confiando que esse servidor não vai te entregar um arquivo comprometido. O SRI resolve isso com um hash criptográfico: o navegador calcula o hash do arquivo baixado e recusa a execução se não bater com o valor declarado.
<script
src="https://cdn.exemplo.com/library.min.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..."
crossorigin="anonymous">
</script>Onde guardar o token do usuário? Comparativo prático
Essa é uma das decisões mais frequentes no front-end — e uma das mais mal tomadas. Muita gente joga o token no localStorage por conveniência, sem pensar nas implicações.
| Opção de armazenamento | Problema principal | Recomendação |
|---|---|---|
| localStorage | Acessível por qualquer script (XSS rouba tudo) | Não use para tokens sensíveis |
| sessionStorage | Mesmo problema do localStorage, só dura a sessão | Evitar para autenticação |
| IndexedDB | Também acessível via JS | Evitar para tokens |
| Cookie HttpOnly+Secure | Inacessível por JavaScript. Mais seguro. | Recomendado para tokens de auth |
A recomendação consolidada: tokens de autenticação devem viver em cookies HttpOnly. Some isso ao atributo Secure (força HTTPS) e SameSite=Strict (mitiga CSRF) e você tem a opção mais segura disponível no front-end.
LGPD no front-end: o compliance começa na sua interface
A LGPD não é só problema do jurídico ou do DPO. O front-end é onde as obrigações de privacidade se tornam reais para o usuário. E onde consentimento é coletado, onde dados são exibidos e onde o usuário exerce (ou não) os seus direitos.
Na prática, isso significa:
- Banners de cookie que permitem recusa granular — não só um botão de aceitar.
- Formulários que coletam apenas o mínimo necessário para o que foi prometido.
- Fluxos claros de exclusão de conta e dados pessoais.
- Notificação transparente ao usuário em caso de incidente.
