tema
Segurança de aplicação
Não é vaga de pentester — é o básico de AppSec que entrevistador de backend e full stack cobra: por que prepared statements matam SQL injection, como XSS acontece e o que o previne, como (e por que assim) guardar senha, e onde um token pode e não pode ficar. Respostas fortes citam o mecanismo, não só o nome do ataque.
Principais perguntas de Segurança de aplicação
ver todas →SQL injection e por que prepared statements resolvem
Injeção = entrada concatenada vira comando. Prepared statement manda comando e dados separados; o valor nunca é interpretado como SQL.
FácilJúniorXSS: como acontece e o que previne
Entrada do atacante roda como script no navegador da vítima. Defesa: encoding de saída por contexto + CSP + cookies HttpOnly.
MédioPlenoComo armazenar senha de usuário
bcrypt/scrypt/Argon2 com salt único por senha e custo calibrado. SHA-256 puro é rápido demais pra resistir a brute force.
MédioPlenoCenário: onde guardar o token de sessão no cliente
localStorage: vulnerável a roubo via XSS. Cookie HttpOnly: protege de XSS mas exige cuidado com CSRF (SameSite). Sem opção livre de trade-off.
DifícilSêniorSegredos fora do código-fonte
Histórico do git é permanente — segredo commitado está queimado. Injete por env/secret manager; se vazou, rotacione já.
FácilJúniorCSRF: o que é e o que realmente o previne
Site malicioso dispara requisição autenticada usando os cookies que o navegador anexa sozinho. Defesa: `SameSite=Lax/Strict` no cookie e/ou token anti-CSRF imprevisível que o atacante não lê.
MédioPlenoCORS não é um mecanismo de segurança do servidor
Falso. CORS relaxa a same-origin policy do navegador (permite JS de A ler resposta de B). Não defende a API — curl/Postman/backends ignoram. A API ainda precisa de auth/authz de verdade.
MédioPlenoOWASP Top 10: pra que serve e o que mudou
Lista das 10 categorias de risco web mais comuns (Broken Access Control no topo hoje). Use como radar pra threat modeling e code review — não como checklist que, cumprido, garante segurança.
FácilJúniorBroken Access Control: IDOR e checar autorização no lugar certo
IDOR: endpoint serve o recurso só pelo id da URL, sem checar posse — trocar o id vaza dados alheios. Autorização tem que rodar no servidor, por requisição, perto do dado (escopar query pelo dono).
MédioPlenoSSRF: quando o servidor faz a requisição do atacante
O atacante faz seu servidor requisitar um alvo que ele escolhe (metadados de cloud, Redis interno, rede privada), emprestando o acesso de rede do servidor. Defesa: allowlist de domínio, bloquear IPs privados, cuidar de redirect/DNS rebinding.
DifícilSêniorDependências vulneráveis e a cadeia de suprimento
Scan de CVE no CI como bug, lockfile commitado, updates regulares com testes, menos dependências, revisar bumps sensíveis. Supply chain: mantenedor invadido, typosquatting, versão maliciosa.
MédioPlenoDefesa em profundidade e menor privilégio
Defesa em profundidade: várias barreiras, cada uma assume que as outras falham. Menor privilégio: cada componente/credencial só tem o acesso necessário. Juntas reduzem o raio de dano de uma falha.
MédioPleno
Perguntas frequentes
O que os entrevistadores mais avaliam em segurança de aplicação?
Não é vaga de pentester — é o básico de AppSec que entrevistador de backend e full stack cobra: por que prepared statements matam SQL injection, como XSS acontece e o que o previne, como (e por que assim) guardar senha, e onde um token pode e não pode ficar. Respostas fortes citam o mecanismo, não só o nome do ataque.
Quanto tempo leva pra treinar segurança de aplicação até me sentir pronto?
Depende do seu ponto de partida, mas a maioria sente diferença depois de 2-3 simulações completas com revisão das perguntas erradas — é aí que os padrões que se repetem em entrevista real ficam visíveis.