Segurança em front-end é aquele tipo de assunto ignorado… até o dia que vira incidente.

E quando vira, não é bug pequeno. É vazamento de dados, sequestro de sessão e execução de código malicioso.

E o pior: muitas dessas falhas nascem no próprio front-end.

Se você quer atuar em nível sênior, precisa entender isso de verdade.

O erro mais comum: “segurança é só backend”

Não é.

O front-end é a porta de entrada.

Se ele permite comportamento inseguro, o backend sofre.

XSS (Cross-Site Scripting): o clássico que continua atual

XSS acontece quando você executa código vindo do usuário.

Exemplo real vulnerável

function Comment({ text }) {
  return (
    <div dangerouslySetInnerHTML={{ __html: text }} />
  );
}

Se alguém enviar:

<script>alert('hackeado')</script>

👉 esse script será executado no navegador de outros usuários

Versão segura

function Comment({ text }) {
  return <div>{text}</div>;
}

O React escapa automaticamente.

Caso você precise renderizar HTML

Use sanitização.

import DOMPurify from 'dompurify';

function SafeComment({ html }) {
  const clean = DOMPurify.sanitize(html);

  return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}

Regra de ouro

👉 nunca confie em input do usuário
👉 nunca renderize HTML sem sanitizar

CSRF (Cross-Site Request Forgery): ataques invisíveis

Aqui o atacante não injeta código.

Ele engana o navegador do usuário.

Cenário clássico

Usuário logado no seu sistema.

Abre outro site malicioso.

Esse site faz:

<img src="https://seusistema.com/api/delete-account" />

Se sua API aceita cookies automaticamente…

👉 ação executada sem o usuário saber

Proteção contra CSRF

1. Usar tokens CSRF

// backend envia token
<meta name="csrf-token" content="abc123" />

// frontend envia junto
fetch('/api/action', {
  method: 'POST',
  headers: {
    'X-CSRF-Token': token,
  },
});

2. SameSite cookies

No backend:

Set-Cookie: session=abc; SameSite=Strict;

👉 impede envio automático em requisições cross-site

Clickjacking: o ataque invisível

Usuário acha que está clicando em algo…

Mas está clicando em outra coisa por trás.

Exemplo de ataque

Seu site é carregado dentro de um iframe invisível.

Usuário clica em “Play”…

👉 mas na verdade clicou em “Transferir dinheiro”.

Proteção

No backend:

X-Frame-Options: DENY

ou

Content-Security-Policy: frame-ancestors 'none';

Armazenamento de tokens: onde muita gente erra

Esse aqui é crítico.

❌ localStorage (perigoso)

localStorage.setItem('token', jwt);

Se houver XSS:

👉 token é roubado facilmente

❌ sessionStorage (mesmo problema)

Ainda vulnerável a XSS.

✅ Cookies HttpOnly (mais seguro)

No backend:

Set-Cookie: token=abc; HttpOnly; Secure; SameSite=Strict;

Agora:

• JS não acessa o token
• reduz impacto de XSS

Trade-off real

Cookies:

• protegem contra XSS
• exigem proteção contra CSRF

👉 segurança sempre é equilíbrio

SPA vs SSR: muda a superfície de ataque

Arquitetura impacta diretamente segurança.

SPA (Single Page Application)

Exemplo com React.

Riscos

• token exposto no client
• dependência forte de JS
• maior superfície para XSS

Exemplo típico

fetch('/api/user', {
  headers: {
    Authorization: `Bearer ${token}`,
  },
});

👉 token precisa existir no front

SSR (Server-Side Rendering)

Exemplo com Next.js.

Vantagens

• menos exposição de token
• lógica sensível pode ficar no servidor

Exemplo

// server component
export async function getUser() {
  const res = await fetch('https://api', {
    headers: {
      cookie: 'session=abc',
    },
  });

  return res.json();
}

👉 token nunca chega ao client

Content Security Policy (CSP): defesa avançada

CSP reduz impacto de XSS.

Exemplo real

Content-Security-Policy:
  default-src 'self';
  script-src 'self';
  object-src 'none';

👉 impede execução de scripts externos maliciosos

Checklist prático (nível produção)

Se você quer subir o nível do seu front:

• não usar dangerouslySetInnerHTML sem sanitizar
• usar cookies HttpOnly para tokens
• implementar proteção contra CSRF
• bloquear iframes (clickjacking)
• configurar CSP
• validar e escapar inputs

O erro mais perigoso

Achar que “nunca vai acontecer”.

Segurança não falha de forma gradual.

Ela falha de uma vez.

E quando falha:

👉 o impacto é grande
👉 o custo é alto
👉 a confiança vai embora

Conclusão: segurança não é feature, é base

Você pode ter:

• performance incrível
• UI perfeita
• arquitetura elegante

Mas sem segurança…

👉 tudo isso não importa

No fim:

👉 júnior foca em funcionalidade
👉 sênior protege o sistema