Vídeo y subtítulos · Descargador directo de medios
Una breve historia de la política del mismo origen y CORS en los navegadores web
· Antecedentes
cors historial web seguridad
La regla que impide que una herramienta de navegador lea libremente los archivos de otro sitio se remonta a los primeros navegadores con secuencias de comandos. Esta publicación rastrea la política del mismo origen, XMLHttpRequest y el estándar CORS que finalmente hizo posible la recuperación controlada entre sitios.
Por qué un navegador se niega a entregarle a su propia pestaña los bytes que acaba de recibir: el efecto cotidiano de una regla de décadas de antigüedad
Un navegador puede mostrar un archivo remoto pero negarse a dar ese cuerpo de respuesta a la página JavaScript. La aparente contradicción es una separación de seguridad entre la navegación y la lectura programática de orígenes cruzados.
Direct Media Downloader encuentra la regla porque debe leer fragmentos en un Blob. El enlace Native Save puede funcionar donde Fetch falla, ya que sigue una ruta de navegador diferente. El rechazo protege las cookies y los recursos de intranet en otras partes del navegador, aunque este descargador en particular omite deliberadamente las credenciales de sus propias llamadas. El límite protege las cookies no relacionadas y las páginas de intranet en el mismo navegador, aunque esta solicitud en particular omita las credenciales.
Netscape, JavaScript y la primera regla de origen: el problema de seguridad que provocó la política del mismo origen
Las primeras secuencias de comandos web hicieron necesario impedir que un sitio leyera las páginas confidenciales de otro a través del acceso ambiental de un visitante. Los navegadores organizaron esa frontera en torno a los orígenes.
Los detalles históricos varían según las implementaciones, por lo que la herencia práctica es más importante: el esquema, el host y el puerto definen un compartimento de confianza para los recursos legibles por script. Tratar un origen como una unidad era un límite de ingeniería que podía aplicarse de manera consistente en documentos, scripts y API de red. La agrupación de orígenes proporcionó una unidad ejecutable que los motores de los navegadores podían aplicar en documentos, scripts, almacenamiento y respuestas de red. El modelo es imperfecto pero ofrece a los desarrolladores un valor predeterminado predecible en lugar de una autoridad ambiental sin restricciones.
XMLHttpRequest y la web aislada: cómo las solicitudes programadas heredaron la regla y por qué los mashups tuvieron problemas
XMLHttpRequest habilitó el trabajo HTTP en segundo plano pero mantuvo las restricciones de origen. Eso hizo que las aplicaciones en el mismo sitio fueran útiles, mientras que los mashups entre sitios requerían cooperación o intermediarios de servidores.
Una anulación universal del cliente habría destruido la protección. El servidor propietario del objetivo necesitaba una forma de expresar qué orígenes externos podían leer las respuestas seleccionadas. Las retransmisiones de servidores se convirtieron en soluciones comunes, pero trasladaron la confianza, el ancho de banda y el riesgo de falsificación de solicitudes a la infraestructura fuera del entorno limitado del navegador. Las soluciones alternativas de retransmisión trasladaron el ancho de banda, la confianza y el riesgo de falsificación de solicitudes del lado del servidor más allá del entorno limitado del cliente en lugar de eliminar la política. Esos intermediarios necesitan sus propios controles de seguridad, privacidad y abuso cuando se implementan intencionalmente.
El estándar CORS: cómo los encabezados de control de acceso permiten que un servidor opte por la lectura entre orígenes sin perder el valor predeterminado
CORS proporciona esa cooperación a través de encabezados de respuesta HTTP interpretados por los navegadores. `Access-Control-Allow-Origin` puede autorizar un origen solicitante o, en casos adecuados sin credenciales, una audiencia más amplia.
El mecanismo no deshabilita la política del mismo origen globalmente. Otorga acceso de lectura con alcance a las respuestas cuyo host elige exponerlas según el protocolo. El navegador puede almacenar en caché los resultados de la verificación previa según las reglas del protocolo, por lo que una auditoría no debe inferir que "nunca se realizó ninguna verificación de políticas" a partir de un seguimiento activo. Esto preserva el aislamiento predeterminado al tiempo que permite a los propietarios de recursos publicar una excepción deliberada para los llamadores y métodos seleccionados.
Verificaciones previas, solicitudes simples y respuestas opacas: el vocabulario que explica la mayoría de los errores de descarga
Algunas solicitudes de origen cruzado son lo suficientemente simples como para no requerir una verificación previa; otros primero envían OPCIONES para preguntar si el método y los encabezados están permitidos. La verificación previa es una negociación, no la transferencia de medios real.
Las respuestas opacas surgen del modo sin cors y ocultan el estado, los encabezados y el cuerpo del script. ToolAcre no selecciona ese modo porque un cuerpo ilegible no puede convertirse en el Blob que se desea guardar. Un error de CORS puede coexistir con una solicitud exitosa del lado del servidor, lo que refuerza por qué el error de la aplicación no significa que el origen no haya recibido nada. Las decisiones de verificación previa almacenadas en caché pueden cambiar lo que aparece en un rastro cálido, por lo que la ausencia histórica de OPCIONES no es prueba de que la negociación nunca existió.
Qué significa CORS para un descargador exclusivo del navegador: el host decide, la herramienta no puede anularlo y la honestidad al respecto es la respuesta correcta
Para este descargador, el host decide si las respuestas HEAD y GET son legibles. ToolAcre no puede adjuntar un encabezado de respuesta de permiso de origen en nombre del host y no transmitirá el cuerpo a través de su propio origen.
El error combina CORS y posibilidades de red porque Fetch retiene deliberadamente información detallada en algunas fallas. DevTools puede revelar más al visitante de lo que recibe el código de la aplicación. Los operadores de host deben autorizar únicamente los orígenes, métodos y encabezados previstos y luego verificar sus respuestas de producción exactas en lugar de depender de la intención de la configuración local. Una lectura bloqueada puede coexistir con un servidor que recibió la solicitud, razón por la cual la interfaz nunca equipara el fallo de la aplicación con la falta de contacto.
Conclusión: una regla que lo protege incluso cuando le molesta: cómo funciona Direct Media Downloader dentro de él y no alrededor de él
La regla protege a los usuarios incluso cuando frustra una transferencia de archivos legítima. Un host que desee que las aplicaciones del navegador lean medios públicos puede configurar respuestas CORS apropiadas; uno que no permanezca inaccesible a través de esta ruta de script.
Direct Media Downloader funciona dentro de ese modelo: valida localmente, solicita abiertamente, explica el rechazo y sugiere guardar de forma nativa cuando sea adecuado. No transforma un límite de seguridad del navegador en un problema de elusión. Comprender ese historial convierte el error de la hostilidad arbitraria del navegador en una consecuencia visible de un modelo de lectura entre sitios de denegación predeterminada. Los propietarios de orígenes deben probar los encabezados de producción exactos para los métodos previstos en lugar de depender únicamente de la configuración de un panel.