Vidéo et sous-titres · Téléchargeur multimédia direct
Un bref historique de la politique de même origine et de CORS dans les navigateurs Web
· Contexte
cors historique Web sécurité
La règle qui empêche un outil de navigation de lire librement les fichiers d'un autre site remonte aux premiers navigateurs à script. Cet article retrace la politique de même origine, XMLHttpRequest et la norme CORS qui ont finalement rendu possible la récupération contrôlée entre sites.
Pourquoi un navigateur refuse de transmettre à votre propre onglet les octets qu'il vient de recevoir : l'effet quotidien d'une règle vieille de plusieurs décennies
Un navigateur peut afficher un fichier distant mais refuser de donner ce corps de réponse à la page JavaScript. La contradiction apparente est une séparation de sécurité entre la navigation et la lecture programmatique d'origine croisée.
Direct Media Downloader rencontre la règle car il doit lire des morceaux dans un Blob. Le lien Enregistrer natif sous peut fonctionner là où Fetch échoue car il suit un chemin de navigateur différent. Le refus protège les cookies et les ressources intranet ailleurs dans le navigateur, même si ce téléchargeur particulier omet délibérément les informations d'identification lors de ses propres appels. La limite protège les cookies et les pages intranet non liés dans le même navigateur, même si cette demande particulière omet les informations d'identification.
Netscape, JavaScript et la première règle d'origine : le problème de sécurité à l'origine de la politique de même origine
Les premiers scripts Web rendaient nécessaire d'empêcher un site de lire les pages sensibles d'un autre site via l'accès ambiant d'un visiteur. Les navigateurs ont organisé cette frontière autour des origines.
Les détails historiques varient selon les implémentations, c'est donc l'héritage pratique qui est le plus important : le schéma, l'hôte et le port définissent un compartiment de confiance pour les ressources lisibles par script. Traiter une origine comme une seule unité représentait une limite technique qui pouvait être appliquée de manière cohérente dans les documents, les scripts et les API réseau. Le regroupement d'origines fournissait une unité exécutoire que les moteurs de navigateur pouvaient appliquer aux documents, aux scripts, au stockage et aux réponses réseau. Le modèle est imparfait mais donne aux développeurs une valeur par défaut prévisible plutôt qu'une autorité ambiante illimitée.
XMLHttpRequest et le Web cloisonné : comment les requêtes scriptées ont hérité de la règle et pourquoi les mashups ont connu des difficultés
XMLHttpRequest a activé le travail HTTP en arrière-plan mais a conservé les restrictions d'origine. Cela rendait les applications sur le même site utiles, tandis que les mashups intersites nécessitaient une coopération ou des intermédiaires de serveur.
Un remplacement universel du client aurait détruit la protection. Le serveur propriétaire de la cible avait besoin d'un moyen d'exprimer quelles origines extérieures pouvaient lire les réponses sélectionnées. Les relais de serveur sont devenus des solutions de contournement courantes, mais ils ont déplacé les risques de confiance, de bande passante et de falsification de requêtes vers l'infrastructure en dehors du bac à sable du navigateur. Les solutions de contournement du relais ont déplacé les risques de bande passante, de confiance et de falsification de requêtes côté serveur au-delà du bac à sable client plutôt que d'éliminer la politique. Ces intermédiaires ont besoin de leurs propres contrôles de sécurité, de confidentialité et d’abus lorsqu’ils sont intentionnellement déployés.
La norme CORS — comment les en-têtes Access-Control permettent à un serveur d'opter pour la lecture d'origine croisée sans assouplir la valeur par défaut
CORS fournit cette coopération via des en-têtes de réponse HTTP interprétés par les navigateurs. `Access-Control-Allow-Origin` peut autoriser une origine requérante ou, dans les cas appropriés sans informations d'identification, un public plus large.
Le mécanisme ne désactive pas globalement la stratégie de même origine. Il accorde un accès en lecture étendu aux réponses dont l'hôte choisit de les exposer sous le protocole. Les résultats du contrôle en amont peuvent être mis en cache par le navigateur selon les règles du protocole, de sorte qu'un audit ne doit pas déduire « aucune vérification de politique n'a jamais eu lieu » à partir d'une seule trace chaude. Cela préserve l'isolement par défaut tout en permettant aux propriétaires de ressources de publier une exception délibérée pour les appelants et les méthodes sélectionnés.
Contrôles en amont, requêtes simples et réponses opaques : le vocabulaire qui explique la plupart des échecs de téléchargement
Certaines demandes d'origine croisée sont suffisamment simples pour ne pas nécessiter de contrôle en amont ; d'autres envoient d'abord OPTIONS pour demander si la méthode et les en-têtes sont autorisés. Le contrôle en amont est une négociation, pas le transfert multimédia proprement dit.
Les réponses opaques proviennent du mode sans cors et masquent l'état, les en-têtes et le corps du script. ToolAcre ne sélectionne pas ce mode car un corps illisible ne peut pas devenir le Blob susceptible d'être enregistré. Une erreur CORS peut coexister avec une requête côté serveur réussie, renforçant ainsi la raison pour laquelle l’échec de l’application ne signifie pas que l’origine n’a rien reçu. Les décisions de contrôle en amont mises en cache peuvent changer ce qui apparaît dans une trace chaleureuse, donc l'absence historique d'OPTIONS n'est pas la preuve que la négociation n'a jamais existé.
Ce que CORS signifie pour un téléchargeur uniquement par navigateur : l'hôte décide, l'outil ne peut pas remplacer, et l'honnêteté à ce sujet est la bonne réponse
Pour ce téléchargeur, l'hôte décide si les réponses HEAD et GET sont lisibles. ToolAcre ne peut pas attacher un en-tête de réponse d'autorisation d'origine au nom de l'hôte, et il ne relayera pas le corps via sa propre origine.
L'erreur combine CORS et les possibilités du réseau, car Fetch retient délibérément des informations précises lors de certains échecs. DevTools peut révéler plus au visiteur que ce que le code de l'application reçoit. Les opérateurs hôtes doivent autoriser uniquement les origines, méthodes et en-têtes prévus, puis vérifier leurs réponses exactes en production plutôt que de se fier à l'intention de configuration locale. Une lecture bloquée peut coexister avec un serveur qui a reçu la requête, c'est pourquoi l'interface n'assimile jamais l'échec de l'application à l'absence de contact.
À retenir : une règle qui vous protège même lorsqu'elle vous ennuie – comment le Direct Media Downloader fonctionne en son sein plutôt qu'autour de lui
La règle protège les utilisateurs même lorsqu'elle fait échouer un transfert de fichiers légitime. Un hôte qui souhaite que les applications de navigateur lisent les médias publics peut configurer les réponses CORS appropriées ; celui qui ne reste pas inaccessible via ce chemin de script.
Direct Media Downloader fonctionne dans ce modèle : validez localement, demandez ouvertement, expliquez le refus et suggérez une sauvegarde native le cas échéant. Cela ne transforme pas une limite de sécurité du navigateur en un problème de contournement. Comprendre cet historique transforme l'erreur due à l'hostilité arbitraire du navigateur en une conséquence visible d'un modèle de lecture intersites avec refus par défaut. Les propriétaires d'origine devraient tester les en-têtes de production exacts pour les méthodes prévues au lieu de se fier uniquement à la configuration d'un tableau de bord.