A resposta HTTP controla boa parte da defesa pelos cabeçalhos: CORS, cookie e proteções.
Boa parte da segurança de um site não está no corpo da resposta, e sim nos cabeçalhos que acompanham cada resposta HTTP. O navegador obedece a esses cabeçalhos, então configurá-los errado (ou esquecê-los) abre ataques sem que uma única linha do seu código esteja com bug.
Dois casos aparecem nesta trilha:
CORS: Access-Control-Allow-Origin diz qual site pode ler suas respostas por JavaScript. Repetir cegamente a origem recebida (aceitar qualquer uma) e ainda marcar Access-Control-Allow-Credentials: true deixa um site malicioso ler os dados autenticados da vítima.
Cookie e proteções: o Set-Cookie de uma sessão deveria trazer HttpOnly (esconde do JavaScript, então um XSS não rouba a sessão), Secure (só por HTTPS) e SameSite (limita o uso entre sites). Faltar HttpOnly deixa document.cookie ler o cookie.
O mesmo pedido com uma política estreita é barrado, e com CORS frouxo ou sem HttpOnly a resposta autenticada vaza para o site do atacante.
A defesa é permitir só origens confiáveis no CORS (nunca repetir o Origin), marcar HttpOnly, Secure e SameSite nos cookies de sessão, e enviar os cabeçalhos de proteção (Content-Security-Policy, X-Content-Type-Options: nosniff, Strict-Transport-Security). São ajustes de configuração, não de código.
