No, esto no es NOT (necesariamente) seguro. Las otras respuestas son en su mayoría correctas, excepto que hacen dos suposiciones (comunes, pero incorrectas): que localhost siempre es 127.0.0.1, y que un servidor web que se ejecuta en su máquina es uno que usted quería ejecutar. ESTAS NO SON ASUNCIONES SEGURAS .
Algunas máquinas, debido a una modificación deliberada para algún propósito o simplemente porque el archivo HOSTS es mínimo (o falta), no definen localhost como 127.0.0.1 (o :: 1 para IPv6) y, por lo tanto, realizan una búsqueda de DNS ese nombre. Por supuesto, el DNS generalmente no es seguro; un atacante en la misma red (o en cualquier lugar entre usted y un servidor DNS dispuesto a declarar con autoridad a qué dirección IP se asigna el "localhost") puede inyectar una respuesta DNS que especifique su propia dirección IP. Su aplicación carga el contenido web del servidor web del atacante. El atacante puede enviar a la víctima el contenido web malintencionado que roba las credenciales a su servicio, roba el contenido de su cuenta, utiliza maliciosamente su cuenta, utiliza los puentes de API de JS a nativo para atacar su dispositivo (o al menos accede maliciosamente a los datos desde el dispositivo móvil la aplicación puede ver), y así sucesivamente.
Bien, ¿y si usó "127.0.0.1" en lugar de "localhost"? Las direcciones IP nunca tienen que pasar por DNS, 127.0.0.1 siempre se enruta a su propia máquina, y debería estar bien, ¿no?
¡Todavía es una mala idea! Los sockets TCP no respetan el aislamiento de privilegios entre usuarios (o entre aplicaciones de espacio aislado). Si su usuario móvil tiene una aplicación incompleta que ejecuta un servidor web en ese puerto, su aplicación se conectará al servidor malicioso en lugar de al que su aplicación intentó iniciar (que no habrá podido vincular el socket, ya que ya está en uso ). Es casi seguro que también puedes incluir eso en la tienda de aplicaciones; no está utilizando ninguna API no permitida ni nada, solo sirve contenido web en un socket de bucle de retorno enlazado a un puerto en particular (igual que usted). De manera similar, en servidores / computadoras de escritorio / computadoras portátiles, si su máquina permite que usuarios que no son administradores accedan de forma remota (a través de SSH, escritorio remoto, etc.), uno de esos usuarios podría activar un servidor web malintencionado en el puerto que utiliza y esperar su aplicación para conectarse a ella.
Por supuesto, incluso sin ningún intento malicioso, toda esta idea es simplemente frágil . Como mencioné anteriormente, no hay garantía de que ningún otro proceso esté ejecutando un servidor web en el mismo puerto que ha elegido. Solo hay 2 ^ 16 de ellos para elegir, y para algunos rangos, el sistema operativo en sí puede vincular aleatoriamente las conexiones salientes a ese puerto, por lo que podría estar en uso por una aplicación cliente (como un navegador web) en lugar de que un servidor De cualquier manera, el servidor utilizado para ofrecer su contenido web no podrá vincular el puerto, su aplicación no podrá comunicarse con el servidor que espera y su usuario tendrá una mala experiencia.
Tenga en cuenta que esto no tiene nada que ver con CORS. A CUALQUIER origen desde el que cargue el contenido, su servidor deberá permitir que ese origen vea las respuestas de la web.
El punto importante es asegurarse de que el contenido web esté cargado de forma segura , y HTTP sobre TCP normal, es decir, sin TLS u otras formas de autenticar y proteger la conexión. ¡No es seguro!
Solución: simplemente cargue el contenido (a través de HTTPS) desde sus servidores web orientados a Internet. Entonces, su aplicación no necesita cargar nada a través de HTTP, su servicio web no necesita permitir ninguna solicitud de ninguna página web cargada a través de HTTP, y la aplicación puede estar segura de que está cargando contenido desde el servidor correcto.
Incluso puede servir el contenido desde el mismo dominio, por lo que las solicitudes de origen cruzado (es decir, CORS) ni siquiera son necesarias. Simplemente use XMLHttpRequests (o Fetch, sin CORS) de la vieja escuela y extraiga todo lo relacionado con CORS del servicio web.
Hora de la historia:
La empresa anterior para la que trabajé tenía un producto que hacía algo como lo que estás describiendo: cargar datos desde un servidor web de localhost en una vista web - y nos encontramos con un problema realmente divertido donde algunas personas informaban que la vista web estaba solo ... vacío Sin contenido. El servidor local se estaba ejecutando, el contenido se empaquetó e instaló correctamente, la vista web intentaba realizar las solicitudes web ... pero parecía que el servidor no estaba respondiendo. En pocas palabras, finalmente lo rastreamos hasta que "localhost" quedara indefinido en esas máquinas. Esto fue solo unos pocos usuarios de aproximadamente 10,000 (en Mac, ya que era la única plataforma que ejecutaba nuestra aplicación), pero fue un problema suficiente que dejamos de usar "localhost". Por supuesto, "127.0.0.1" tampoco resultó ser seguro, como expliqué anteriormente, pero esa decisión se tomó antes de que hubiera una persona de seguridad en el equipo.