Segurança costuma ser tratada como "problema do back-end", mas o navegador é a linha de frente e o front-end carrega responsabilidades reais. XSS, CSRF e CORS são os três temas que mais geram confusão — e desmistificá-los, sabendo o que é de fato sua responsabilidade, é o que se espera de um sênior.
XSS: código injetado na sua página
O Cross-Site Scripting acontece quando um atacante consegue injetar JavaScript que roda no navegador de outros usuários — roubando cookies, sessão, ou agindo como a vítima. Há três sabores:
- Stored: o script malicioso é salvo no servidor (ex.: num comentário) e servido a todos.
- Reflected: o script vem na URL/requisição e é refletido de volta na resposta.
- DOM-based: o problema é puramente no JS do cliente, que joga dado não confiável no DOM.
Defendendo de XSS
A regra de ouro: nunca confie em entrada e sempre escape a saída conforme o contexto. Frameworks modernos escapam por padrão ao renderizar texto — o perigo mora nas brechas como innerHTML ou dangerouslySetInnerHTML.
// PERIGOSO: interpreta HTML do usuário
el.innerHTML = comentarioDoUsuario;
// SEGURO: trata como texto puro
el.textContent = comentarioDoUsuario;Como segunda camada, o CSP (Content Security Policy) é um header que diz ao navegador de onde scripts podem vir, bloqueando código injetado mesmo que ele passe. Defesa em profundidade.
CSRF: usar sua sessão sem você saber
O Cross-Site Request Forgery explora o fato de o navegador enviar seus cookies automaticamente. Um site malicioso faz seu navegador disparar uma requisição para um site onde você está logado — e o servidor, vendo o cookie válido, executa a ação como se fosse você (ex.: transferir dinheiro).
Defendendo de CSRF
- Token anti-CSRF: um valor imprevisível que só sua página conhece e envia junto; o site atacante não consegue adivinhá-lo.
- Cookie
SameSite: instrui o navegador a não enviar o cookie em requisições vindas de outros sites.
Set-Cookie: sessao=abc; SameSite=Strict; Secure; HttpOnly| XSS | CSRF | |
|---|---|---|
| O que explora | Confiança do usuário no site | Confiança do site no usuário |
| Ataque | Injeta e roda script | Força uma ação autenticada |
| Defesa-chave | Escapar saída + CSP | Token + SameSite |
CORS: o mal-entendido número um
Talvez nenhum tema gere mais confusão. O CORS não é uma proteção do seu servidor que você "desliga". É uma política do navegador: por padrão (same-origin policy), o JS de um site não pode ler respostas de outra origem. O CORS é o mecanismo pelo qual um servidor autoriza origens específicas a lerem suas respostas.
Para requisições "não simples", o navegador faz antes um preflight: um OPTIONS perguntando "posso?". Se o servidor responde com os headers certos, a requisição real prossegue.
O equívoco clássico: "desabilitar o CORS para resolver o erro". Você não desabilita o CORS — você configura o servidor para permitir as origens certas. Pôr Access-Control-Allow-Origin: * em uma API com credenciais é abrir a porta, não consertar a fechadura.
É importante entender: CORS protege o usuário (impede que um site leia dados de outro em nome dele), não protege sua API contra acesso direto. Quem chama sua API por fora do navegador (curl, outro back-end) ignora CORS completamente — a autorização real é autenticação no servidor.
O que é responsabilidade do front
- Tratar toda entrada/saída como suspeita: escapar antes de inserir no DOM.
- Evitar
innerHTMLcom dados de usuário; sanitizar quando inevitável. - Configurar e respeitar CSP e cookies
SameSite/HttpOnly. - Entender CORS para diagnosticar (e não "burlar") erros de origem.
- Nunca guardar segredos no front: tudo que vai ao navegador é público.
É comum em entrevista pedir para você diferenciar XSS de CSRF ou explicar por que CORS não é uma defesa do servidor. No dia a dia, isso aparece no primeiro erro de "blocked by CORS policy" ou numa revisão de código que flagra um innerHTML perigoso.
Conclusão
XSS injeta script (escape a saída e use CSP), CSRF abusa da sessão (token e SameSite) e CORS é uma política do navegador para autorizar leitura entre origens — não um interruptor de segurança. Segurança no front é, acima de tudo, desconfiar de todo dado e entender de quem é cada responsabilidade.
Security is often treated as a "back-end problem", but the browser is the front line and the front end carries real responsibilities. XSS, CSRF and CORS are the three topics that generate the most confusion — and demystifying them, knowing what is actually your responsibility, is what's expected of a senior.
XSS: code injected into your page
Cross-Site Scripting happens when an attacker manages to inject JavaScript that runs in other users' browsers — stealing cookies, sessions, or acting as the victim. There are three flavors:
- Stored: the malicious script is saved on the server (e.g., in a comment) and served to everyone.
- Reflected: the script comes in the URL/request and is reflected back in the response.
- DOM-based: the problem is purely in the client's JS, which dumps untrusted data into the DOM.
Defending against XSS
The golden rule: never trust input and always escape output according to context. Modern frameworks escape by default when rendering text — the danger lives in loopholes like innerHTML or dangerouslySetInnerHTML.
// DANGEROUS: interprets the user's HTML
el.innerHTML = comentarioDoUsuario;
// SAFE: treats it as plain text
el.textContent = comentarioDoUsuario;As a second layer, CSP (Content Security Policy) is a header that tells the browser where scripts may come from, blocking injected code even if it slips through. Defense in depth.
CSRF: using your session without your knowledge
Cross-Site Request Forgery exploits the fact that the browser sends your cookies automatically. A malicious site makes your browser fire a request to a site where you're logged in — and the server, seeing the valid cookie, performs the action as if it were you (e.g., transferring money).
Defending against CSRF
- Anti-CSRF token: an unpredictable value that only your page knows and sends along; the attacker's site can't guess it.
SameSitecookie: tells the browser not to send the cookie on requests coming from other sites.
Set-Cookie: sessao=abc; SameSite=Strict; Secure; HttpOnly| XSS | CSRF | |
|---|---|---|
| What it exploits | The user's trust in the site | The site's trust in the user |
| Attack | Injects and runs script | Forces an authenticated action |
| Key defense | Escape output + CSP | Token + SameSite |
CORS: misunderstanding number one
Perhaps no topic causes more confusion. CORS is not a protection of your server that you "turn off". It's a policy of the browser: by default (same-origin policy), one site's JS cannot read responses from another origin. CORS is the mechanism by which a server authorizes specific origins to read its responses.
For "non-simple" requests, the browser first makes a preflight: an OPTIONS asking "may I?". If the server answers with the right headers, the real request proceeds.
The classic mistake: "disabling CORS to fix the error". You don't disable CORS — you configure the server to allow the right origins. Putting Access-Control-Allow-Origin: * on an API with credentials is opening the door, not fixing the lock.
It's important to understand: CORS protects the user (it stops one site from reading another's data on their behalf), it does not protect your API against direct access. Anyone calling your API from outside the browser (curl, another back end) ignores CORS completely — real authorization is authentication on the server.
What is the front end's responsibility
- Treat all input/output as suspect: escape before inserting into the DOM.
- Avoid
innerHTMLwith user data; sanitize when unavoidable. - Configure and respect CSP and
SameSite/HttpOnlycookies. - Understand CORS to diagnose (not "get around") origin errors.
- Never store secrets in the front end: everything that goes to the browser is public.
Interviews commonly ask you to tell XSS from CSRF or explain why CORS is not a server defense. Day to day, it shows up in the first "blocked by CORS policy" error or in a code review that catches a dangerous innerHTML.
Conclusion
XSS injects script (escape output and use CSP), CSRF abuses the session (token and SameSite) and CORS is a browser policy for authorizing cross-origin reads — not a security switch. Front-end security is, above all, distrusting all data and understanding who owns each responsibility.