Vídeo e legendas · Downloader direto de mídia
Um breve histórico da política de mesma origem e CORS em navegadores da web
· Fundo
corpo histórico da web segurança
A regra que impede uma ferramenta de navegador de ler livremente os arquivos de outro site remonta aos primeiros navegadores de script. Esta postagem rastreia a política de mesma origem, XMLHttpRequest e o padrão CORS que eventualmente tornou possível a busca controlada entre sites.
Por que um navegador se recusa a entregar à sua própria guia os bytes que acabou de receber – o efeito cotidiano de uma regra de décadas
Um navegador pode exibir um arquivo remoto, mas se recusar a fornecer esse corpo de resposta à página JavaScript. A aparente contradição é uma separação de segurança entre navegação e leitura programática de origem cruzada.
O Direct Media Downloader encontra a regra porque deve ler pedaços em um Blob. O link Salvar nativo pode funcionar onde o Fetch falha, pois segue um caminho de navegador diferente. A recusa protege cookies e recursos da intranet em outras partes do navegador, mesmo que esse downloader específico omita deliberadamente as credenciais de suas próprias chamadas. O limite protege cookies não relacionados e páginas de intranet no mesmo navegador, mesmo que essa solicitação específica omita credenciais.
Netscape, JavaScript e a primeira regra de origem — o problema de segurança que motivou a política de mesma origem
Os primeiros scripts da web tornaram necessário impedir que um site lesse as páginas confidenciais de outro site por meio do acesso ambiental do visitante. Os navegadores organizaram essa fronteira em torno das origens.
Os detalhes históricos variam entre as implementações, portanto a herança prática é mais importante: esquema, host e porta definem um compartimento confiável para recursos legíveis por script. Tratar uma origem como uma unidade era um limite de engenharia que poderia ser aplicado de forma consistente em documentos, scripts e APIs de rede. O agrupamento de origem forneceu uma unidade executável que os mecanismos do navegador poderiam aplicar em documentos, scripts, armazenamento e respostas de rede. O modelo é imperfeito, mas oferece aos desenvolvedores um padrão previsível, em vez de autoridade ambiental irrestrita.
XMLHttpRequest e a web isolada — como as solicitações com script herdaram a regra e por que os mashups tiveram dificuldades
XMLHttpRequest habilitou o trabalho em segundo plano HTTP, mas manteve as restrições de origem. Isso tornou os aplicativos no mesmo site úteis, enquanto os mashups entre sites exigiam cooperação ou intermediários de servidores.
Uma substituição universal do cliente teria destruído a proteção. O servidor proprietário do alvo precisava de uma maneira de expressar quais origens externas poderiam ler as respostas selecionadas. As retransmissões de servidor tornaram-se soluções alternativas comuns, mas transferiram a confiança, a largura de banda e o risco de falsificação de solicitações para a infraestrutura fora da sandbox do navegador. As soluções alternativas de retransmissão transferiram a largura de banda, a confiança e o risco de falsificação de solicitações do lado do servidor para além da sandbox do cliente, em vez de eliminar a política. Esses intermediários precisam de seus próprios controles de segurança, privacidade e abuso quando são implantados intencionalmente.
O padrão CORS — como os cabeçalhos de controle de acesso permitem que um servidor opte pela leitura de origem cruzada sem afrouxar o padrão
CORS fornece essa cooperação por meio de cabeçalhos de resposta HTTP interpretados pelos navegadores. `Access-Control-Allow-Origin` pode autorizar uma origem solicitante ou, em casos adequados sem credenciais, um público mais amplo.
O mecanismo não desativa globalmente a política de mesma origem. Ele concede acesso de leitura com escopo definido às respostas cujo host escolhe expô-las sob o protocolo. Os resultados da simulação podem ser armazenados em cache pelo navegador de acordo com as regras do protocolo, portanto, uma auditoria não deve inferir “nenhuma verificação de política ocorreu” a partir de um rastreamento quente. Isto preserva o isolamento padrão enquanto permite que os proprietários de recursos publiquem uma exceção deliberada para chamadores e métodos selecionados.
Comprovações, solicitações simples e respostas opacas — o vocabulário que explica a maioria das falhas de download
Algumas solicitações de origem cruzada são simples o suficiente para não exigirem uma simulação; outros primeiro enviam OPTIONS para perguntar se métodos e cabeçalhos são permitidos. A comprovação é uma negociação, não a transferência de mídia propriamente dita.
As respostas opacas surgem do modo sem cors e ocultam o status, os cabeçalhos e o corpo do script. ToolAcre não seleciona esse modo porque um corpo ilegível não pode se tornar o Blob salvável pretendido. Um erro CORS pode coexistir com uma solicitação bem-sucedida do lado do servidor, reforçando porque a falha do aplicativo não significa que a origem não recebeu nada. As decisões de simulação armazenadas em cache podem alterar o que aparece em um rastreamento quente, portanto, a ausência histórica de OPTIONS não é prova de que a negociação nunca existiu.
O que CORS significa para um downloader somente para navegador - o host decide, a ferramenta não pode substituir e a honestidade sobre isso é a resposta certa
Para este downloader, o host decide se as respostas HEAD e GET são legíveis. ToolAcre não pode anexar um cabeçalho de resposta de permissão de origem em nome do host e não retransmitirá o corpo por meio de sua própria origem.
O erro combina CORS e possibilidades de rede porque o Fetch retém deliberadamente informações refinadas em algumas falhas. DevTools podem revelar mais ao visitante do que o código do aplicativo recebe. Os operadores de host devem autorizar apenas as origens, métodos e cabeçalhos pretendidos e, em seguida, verificar suas respostas exatas de produção, em vez de confiar na intenção de configuração local. Uma leitura bloqueada pode coexistir com um servidor que recebeu a solicitação, e é por isso que a interface nunca equipara a falha do aplicativo à ausência de contato.
Conclusão: uma regra que protege você mesmo quando incomoda - como o Direct Media Downloader funciona dentro dela e não em torno dela
A regra protege os usuários mesmo quando frustra uma transferência legítima de arquivos. Um host que deseja que os aplicativos do navegador leiam mídia pública pode configurar respostas CORS apropriadas; aquele que não permanece inacessível através deste caminho de script.
O Direct Media Downloader funciona dentro desse modelo: valida localmente, solicita abertamente, explica a recusa e sugere salvamento nativo quando adequado. Isso não transforma um limite de segurança do navegador em um problema de contorno. A compreensão desse histórico transforma o erro da hostilidade arbitrária do navegador em uma consequência visível de um modelo de leitura entre sites de negação padrão. Os proprietários de origem devem testar os cabeçalhos de produção exatos para os métodos pretendidos, em vez de depender apenas de uma configuração de painel.