Renderize dados não confiáveis como texto, nunca como marcação: deixe o framework escapar e evite innerHTML, dangerouslySetInnerHTML e v-html. Se você precisa aceitar HTML, sanitize no servidor ou com um sanitizador mantido antes de encostar no DOM. Adicione uma Content Security Policy com nonces para eliminar script inline como opção, valide URLs para que esquemas javascript não parem num href, e mantenha tokens fora de qualquer armazenamento que scripts consigam ler.
Por que os entrevistadores perguntam isso
Frameworks escapam por padrão, então entrevistadores querem saber se você entende os buracos que restam: injeção de HTML cru, sinks de atributo e de URL, e scripts de terceiros. A resposta mostra se você pensa em termos de origens e sinks ou se só lembra de escapar. Citar CSP e trusted types sinaliza que você já entregou defesa em profundidade em vez de presumir que o framework cuida de tudo.
Como estruturar sua resposta
- Comece pelo padrão: escapar renderizando como texto.
- Nomeie os sinks específicos que passam por cima do framework.
- Cubra injeção em URL e atributo, não só conteúdo de elemento.
- Some as defesas em camadas: CSP, sanitizador, armazenamento de tokens.
Exemplo de resposta
A linha de base é que tudo que não é confiável é renderizado como texto, o que o framework faz por mim. Então o trabalho real é auditar os lugares que optam por sair disso. Qualquer innerHTML, qualquer dangerouslySetInnerHTML, qualquer template que escreva marcação crua, mais os sinks que as pessoas esquecem: um href construído a partir de entrada do usuário pode carregar um esquema javascript, e um atributo style ou srcdoc é igualmente perigoso. Se uma funcionalidade genuinamente precisa de rich text, por exemplo descrições escritas por usuários, eu sanitizo com uma biblioteca mantida e uma lista de permissões em vez de tentar filtrar tags eu mesmo, e faço isso o mais perto do armazenamento possível. Além disso quero uma Content Security Policy com nonce para que script inline simplesmente não execute, o que transforma a maioria dos bugs residuais numa mensagem bloqueada no console em vez de uma brecha. E mantenho tokens de sessão em cookies HttpOnly, porque se um payload chegar, o raio de impacto não deveria incluir a sessão do usuário.
Vai encarar essa entrevista em breve? O GhostPilot escuta a sua chamada ao vivo, identifica a pergunta no instante em que ela é feita e coloca uma resposta estruturada na sua tela em tempo real. Teste na sua próxima entrevista simulada ou pegue um Session Pass de $29, sem assinatura, para a hora da verdade.
Veja como funcionaPerguntas de acompanhamento que você pode esperar
- Onde uma Content Security Policy não te ajuda?
- Como você renderizaria com segurança rich text enviado por usuários?
- O que é XSS baseado em DOM, e por que filtros do lado do servidor não pegam?
Mais perguntas para Desenvolvedor Frontend
Seu entrevistador vai fazer a própria versão desta. Cole a descrição real da vaga no Question Predictor gratuito e receba as 20 perguntas que essa vaga tem mais chance de fazer, com o que cada uma está de fato sondando.
Prever minhas perguntas