A Same-Origin Policy é um mecanismo de segurança fundamental do navegador que restringe como um documento ou script carregado de uma origem pode interagir com recursos de outras origens. Ela ajuda a impedir que sites maliciosos leiam dados sensíveis de outros sites. A política considera que duas URLs têm a mesma origem se compartilham o mesmo protocolo, host e número de porta.
A same-origin policy (SOP) é a regra de isolamento fundamental do navegador. Ela considera dois URLs como sendo a mesma origem apenas quando compartilham o mesmo esquema, host e porta, então https://shop.example:443 e http://shop.example ou https://api.example são origens diferentes. Sob a SOP, um script rodando em uma origem pode carregar alguns recursos de outra origem (imagens, scripts, estilos), mas não pode ler as respostas, inspecionar o DOM de outra origem ou acessar seus cookies, localStorage e IndexedDB. A política é imposta pelo próprio navegador, não pelo servidor, e se aplica por origem, e não por página. Sem ela, qualquer aba que você abrisse poderia ler silenciosamente sua sessão de webmail ou do banco em outra aba.
A SOP é o que impede um site malicioso de manipular via script suas sessões autenticadas em outros lugares. Como os navegadores anexam seus cookies às requisições automaticamente, uma página poderia, de outra forma, fazer um fetch ao seu banco e ler o saldo da conta na resposta. A SOP bloqueia essa leitura, e é por isso que a falsificação de requisições entre sites (cross-site request forgery) e o roubo de dados entre origens ficam limitados. Ela não é absoluta: governa a leitura, não o envio, então requisições que alteram estado ainda podem disparar, e um CORS mal configurado, handlers de postMessage permissivos ou um XSS rodando dentro da origem confiável tudo isso a contorna. A SOP é uma fronteira entre origens, não uma defesa contra código que já é executado dentro da sua própria origem.
Trate a SOP como um padrão a preservar, não como um obstáculo a contornar. Quando você realmente precisar de acesso entre origens, use CORS com uma allowlist restrita em vez de refletir origens arbitrárias ou usar curinga em endpoints com credenciais. Valide a origem de cada evento postMessage antes de agir com base nele, defina o escopo dos cookies com cuidado e mantenha os tokens de autenticação fora do localStorage, onde qualquer script da mesma origem pode lê-los. A brecha mais difícil de fechar é um script que roda dentro da sua própria origem, já que a SOP lhe concede confiança total. Monitorar o que seus scripts de terceiros de fato fazem em tempo de execução, que é o cerne da segurança client-side, é como você detecta o abuso dessa confiança herdada.
Não. A SOP restringe a leitura de respostas de outras origens, não o envio das requisições. Uma página ainda pode enviar uma requisição para outra origem, e o navegador anexa seus cookies. A SOP simplesmente impede que a página que envia leia o que volta, e é por isso que defesas contra CSRF, como cookies SameSite e tokens, continuam sendo necessárias.
Não. app.example.com e api.example.com são origens diferentes porque o host difere, então a SOP os isola por padrão. Sites relacionados podem flexibilizar algumas interações por meio de cabeçalhos CORS ou, em casos legados restritos, com document.domain, mas os navegadores restringem cada vez mais essas brechas em favor de CORS explícito.
We answer client-side security questions every day. Bring yours.