Esta pergunta é uma espécie de duplicata de:Por que a mesma política de origem para XMLHttpRequest

No entanto, essa resposta não é satisfatória porque não aborda o fato de que existem soluções alternativas (conforme declarado na pergunta). A resposta aborda apenas preocupações de segurança relacionadas diretamente ao XMLHttpRequest, mas esses problemas ainda estão presentes no JSONP (e possivelmente no CORS, não tenho certeza). Portanto, a questão permanece: por que ter uma política estrita de mesma origem, quando existem soluções alternativas como JSONP, sem dúvida ainda piores (porque é executável em vez de conteúdo estático)?

Aqui está um exemplo: Company.com quer fazer uma chamada AJAX para algum recurso não protegido, como uma API pública simples para alguma pesquisa de dados. A Company.com percebe que isso pode ser inseguro e, portanto, eles limpam cuidadosamente os dados para garantir que não haja assuntos engraçados. No entanto, XMLHttpRequest não permite isso, portanto, o Company.com deve usar JSONP, mas isso evitaria a lavagem de dados e poderia resultar em um atacante injetando Javascript arbitrário na página. Como isso é uma solução melhor?

Outro exemplo: o Company.com tem uma vulnerabilidade e um invasor é capaz de injetar Javascript na página que é visível por algum usuário (existem milhões de maneiras de isso acontecer; é provavelmente o ataque mais comum do site). Com uma política estrita de mesma origem, o invasor pode mexer com a página o dia inteiro, mas não pode "ligar para casa", o que é um detalhe importante porque significa que todos os seus dados estão seguros. Mas o JSONP (e as tags de imagem) quebram isso, permitindo que o invasor raspe todos os seus dados pessoais da página e os envie para qualquer lugar. Isso ainda é uma realidade, mesmo com o CORS, porque posso dizer ao meu servidor invasor para permitir solicitações XS de entrada de qualquer domínio.

Em outras palavras, em que cenário um XMLHttpRequest bloqueado realmente fornece um maior grau de segurança?