Este equipo de trabajo ha estado mucho tiempo investigando soluciones a tu búsqueda, te regalamos la solución así que deseamos resultarte de mucha apoyo.
Solución:
Si lo entiendo correctamente, ¿está diciendo por qué el navegador bloquea el acceso a un recurso que se puede obtener libremente a través de Internet si no hay cookies involucradas? Bueno, considere este escenario:
www.evil.com – contiene un código de script malicioso que busca explotar las vulnerabilidades CSRF.
www.privatesite.com – este es su sitio externo, pero en lugar de bloquearlo con credenciales, lo configuró para que no tenga cookies y solo permita el acceso desde el enrutador de su hogar static IP.
mynas (192.168.1.1) – este es su servidor doméstico, solo accesible en su red wifi doméstica. Dado que usted es el único que permite conectarse a la red wifi de su hogar, este servidor no está protegido por credenciales y permite el acceso anónimo y sin cookies.
Ambas cosas www.privatesite.com y mynas genere tokens en campos de formulario ocultos para la protección contra CSRF, pero dado que ha deshabilitado la autenticación, estos tokens no están vinculados a ninguna sesión de usuario.
Ahora, si accidentalmente visitas www.evil.com este dominio podría estar realizando solicitudes a www.privatesite.com/turn_off_ip_lockdown pasando el token obtenido por la solicitud de dominio cruzado, o incluso para mynas/format_drive utilizando el mismo método.
Es poco probable, lo sé, pero supongo que el estándar está escrito para ser lo más sólido posible y no tiene sentido eliminarlo. Access-Control-Allow-Origin ya que agrega beneficio en escenarios como este.
Lo que inicialmente me molestó con las políticas de CORS fue su aplicación indiscriminada, independientemente del recurso/tipo, creo que ese sentimiento resuena bastante bien con su pregunta. La especificación W3 en realidad aconseja que:
Un recurso que es de acceso público, sin comprobaciones de control de acceso, siempre puede devolver de forma segura un encabezado Access-Control-Allow-Origin cuyo valor es “*”
Entonces, si bien el escenario en la respuesta de @SilverlightFox es posible, en mi humilde opinión, era poco probable que se considerara al escribir la especificación. En cambio, W3 parece ser impulsado por un “todo lo que no está explícitamente permitido debe ser restringido” mentalidad en este caso, que resulta contraproducente cuando los encabezados correctos no están configurados o los navegadores individuales carecen de soporte:
-
Aplicaciones enriquecidas del lado del cliente que utilizan API RESTful de terceros donde la autenticación, si la hay, se envía con cada solicitud para que no haya una “sesión” para secuestrar (¡eso es sin estado para usted!). Aún así, las respuestas .json están sujetas a CORS, por lo que ahora debe convencer al tercero para que implemente
jsonpo un adecuadoAccess-Control-Allow-Originencabezado, o darse por vencido y configurar un túnel a su punto final (adivina cuál usaré). -
Las fuentes web están sujetas a CORS, aunque afaik solo Firefox implementó este borrador de especificación. Esto significa que si está utilizando un CDN para fuentes (o un subdominio para todos static contenido), es mejor que sea
*-¡activado! -
Prima herp derp puntos para CDN que no responden con un
*encabezado pero repite la solicitudOriginvalor de encabezado en su lugar: si se almacena en caché en un proxy con un...-Allow-Origin: domainAsus usuarios de otros dominios no podrán acceder a él sin cachebusting (que es una especie de retroceso en términos de beneficios de rendimiento de CDN). -
También hay algunos escenarios marginales como el uso de imágenes/videos externos con
canvas.
Estos inconvenientes al acceder *-los recursos adecuados podrían simplemente considerarse aceptables ya que al menos CORS está en juego de forma predeterminada cuando más importa.
Si te gustó nuestro trabajo, puedes dejar una crónica acerca de qué te ha gustado de esta noticia.