O pedido que atravessa o mundo
Tudo nesta trilha começa com um fato simples que a rotina esconde: cada clique viaja. O navegador monta um pedido HTTP, ele atravessa redes que você não controla, chega a um servidor que responde o que quiser, e a resposta volta para ser interpretada por um programa que roda na máquina de outra pessoa, o navegador. Para quem desenvolve, HTTP é transporte. Para quem defende, HTTP é contrato: cada cabeçalho, cada cookie e cada byte do corpo são dados que atravessaram território hostil e chegam afirmando ser o que são. A pergunta fundacional da segurança de aplicações é exatamente essa: em que ponto do caminho alguém poderia ter mentido. O servidor mente se confia em cabeçalho que o cliente forja. O cliente mente se executa resposta que o servidor não devia mandar. O meio mente se nada verifica a integridade do trânsito. Este módulo monta esse mapa, porque cada vulnerabilidade das próximas mora em um ponto dele.
Same-origin: a fronteira dentro do navegador
O navegador executa código de sites diferentes na mesma máquina, então precisa de uma cerca interna: a política de mesma origem. Origem é o trio esquema, host e porta: https://app.exemplo.com e https://docs.exemplo.com são origens diferentes, e http://app.exemplo.com difere de https://app.exemplo.com só pelo esquema e mesmo assim são origens distintas. A política diz, em resumo: JavaScript de uma origem não lê a resposta de outra. É o que impede a aba do banco de ler a aba do webmail. As brechas controladas dessa cerca são precisamente as superfícies de ataque que o resto do curso estuda: o CORS relaxa a leitura com permissão explícita, o carregamento de scripts de terceiros introduz código de outra origem com os poderes da sua, e o postMessage abre um canal entre janelas que precisa de verificação de origem. Quando alguém pergunta por que XSS é grave, a resposta curta é: o XSS derruba a cerca que a mesma origem construiu, porque o script injetado roda na própria origem da vítima.
Quem roda onde: servidor, navegador e a mentira do segredo no cliente
Toda aplicação web tem código em dois lugares, e a fronteira entre eles é a linha mais mal entendida da segurança de aplicações. No servidor, o código roda em ambiente que você controla, com acesso a banco, chaves e lógica sensível, invisível ao usuário. No navegador, o código é entregue por HTTP e pode ser lido, alterado e depurado por quem o recebeu. A consequência é uma regra sem exceção: segredo e decisão de segurança nunca moram no cliente. Valor escondido em campo de formulário, chave de API embutida no JavaScript, verificação de permissão só no front: tudo isso é decorativo, porque o atacante simplesmente abre as ferramentas de desenvolvedor. O formulário que esconde o campo de preço não impede a compra alterada; o script que carrega uma chave de mapa não protege a cota da chave. O cliente decide experiência, o servidor decide verdade. Cada módulo seguinte vai reencontrar essa regra disfarçada em vulnerabilidade diferente.