Cross-Origin Resource Sharing ou CORS é um mecanismo que permite que recursos restritos em uma página da web sejam recuperados por outro domínio fora do domínio ao qual pertence o recurso que será recuperado. Uma página da web pode integrar livremente recursos de diferentes origens, como imagens, folhas de estilo, scripts, iframes e vídeos. Certas "solicitações de domínio cruzado", em particular as solicitações Ajax, são proibidas por padrão pela política de segurança de mesma origem.
CORS define uma maneira pela qual um navegador e um servidor podem interagir para determinar se é ou não seguro permitir uma solicitação de origem cruzada. Isso permite mais liberdade e funcionalidade do que as solicitações da mesma origem, mas é mais seguro do que a simples autorização para ter todas as solicitações de origem cruzada. O padrão para CORS foi publicado originalmente como uma recomendação W3C, mas este documento está obsoleto. A especificação mantida ativamente que define o CORS é o Fetch Living Standard do WHATWG.
Histórico
O suporte de origem cruzada foi originalmente proposto por Matt Oshry, Brad Porter e Michael Bodell da Tellme Networks em março de 2004 para inclusão no VoiceXML 2.1, a fim de permitir consultas seguras de origem cruzada por navegadores VoiceXML. O mecanismo foi considerado de natureza geral e não específico para VoiceXML e foi subsequentemente separado em uma nota de implementação. O grupo de trabalho W3C WebApps, com a participação dos principais fornecedores de navegadores, começou a formalizar a nota em um rascunho de trabalho do W3C direcionado a uma recomendação formal do W3C.
Em maio de 2006, o primeiro esboço do projeto W3C foi apresentado. Em março de 2009, o projeto foi renomeado para "Cross-Origin Resource sharing" e, em janeiro de 2014, foi aceito como uma recomendação W3C.
Como funciona o CORS
O padrão CORS descreve novos cabeçalhos HTTP que fornecem aos navegadores e servidores uma maneira de solicitar uma URL remota apenas se eles tiverem permissão. Embora certas validações e autorizações possam ser realizadas pelo servidor, geralmente é responsabilidade do navegador oferecer suporte a esses cabeçalhos e honrar as restrições que eles impõem.
Para métodos de solicitação Ajax e HTTP que podem modificar dados (geralmente métodos HTTP diferentes de GET, ou para usar POST com alguns tipos MIME), a especificação exige que os navegadores "verifiquem a solicitação upstream", solicitando os métodos suportados pelo servidor através de um método de pedido HTTP OPTIONS e, em seguida, após "aprovação" do servidor, enviar o pedido real com o método de pedido HTTP. Os servidores também podem notificar os clientes se "credenciais" (incluindo cookies e dados de autenticação HTTP) devem ser enviadas com a solicitação.
Ficheiro:Flowchart_showing_Simple_and_Preflight_XHR.svg
CORS e JSONP
O CORS pode ser usado como uma alternativa moderna ao modelo JSONP. Enquanto o JSONP oferece suporte apenas ao método de solicitação GET, o CORS também oferece suporte a outros tipos de solicitações HTTP. O CORS permite que o programador da web use o XMLHttpRequest usual, que tem melhor tratamento de erros do que JSONP. Por outro lado, o JSONP funciona em navegadores mais antigos que são anteriores ao suporte ao CORS. CORS é compatível com a maioria dos navegadores da web modernos. Além disso, enquanto o JSONP pode causar problemas de segurança de cross-site scripting (XSS) quando o site está comprometido, o CORS permite que os sites processem manualmente as respostas para aumentar a segurança.
Ligações externas W3C Working Draft Usage guide enable cross-origin resource sharing
Categoria:Normas W3C Categoria:Ajax (programação)