Al responder con Access-Control-Allow-Origin: *, el recurso solicitado permite compartir con cada origen. Esto básicamente significa que cualquier sitio puede enviar una solicitud XHR a su sitio y acceder a la respuesta del servidor, lo que no sería el caso si no hubiera implementado esta respuesta CORS.
Por lo tanto, cualquier sitio puede hacer una solicitud a su sitio en nombre de sus visitantes y procesar su respuesta. Si tiene algo implementado como un esquema de autenticación o autorización que se basa en algo que el navegador proporciona automáticamente (cookies, sesiones basadas en cookies, etc.), las solicitudes activadas por los sitios de terceros también los usarán.
De hecho, esto plantea un riesgo de seguridad, especialmente si permite compartir recursos no solo para los recursos seleccionados sino para todos los recursos. En este contexto, debería echar un vistazo a ¿ Cuándo es seguro habilitar CORS? .
Access-Control-Allow-Origin: *? No habrá nogin, etc., ¿son públicos para todos?Access-Control-Allow-Origin: *es totalmente seguro agregarlo a cualquier recurso, a menos que ese recurso contenga datos privados protegidos por algo distinto a las credenciales estándar (cookies, autenticación básica, certificados de cliente TLS).Por ejemplo: los datos protegidos por cookies son seguros
Imagine
https://example.com/users-private-data, que puede exponer datos privados según el estado de inicio de sesión del usuario. Este estado usa una cookie de sesión. Es seguro agregarAccess-Control-Allow-Origin: *a este recurso, ya que este encabezado solo permite el acceso a la respuesta si la solicitud se realiza sin cookies, y se requieren cookies para obtener los datos privados. Como resultado, no se filtran datos privados.Por ejemplo: los datos protegidos por ubicación / ip / red interna no son seguros (desafortunadamente común con intranets y electrodomésticos):
Imagine
https://intranet.example.com/company-private-data, que expone los datos de la empresa privada, pero solo se puede acceder si está en la red wifi de la empresa. No es seguro agregarAccess-Control-Allow-Origin: *a este recurso, ya que está protegido con algo más que las credenciales estándar. De lo contrario, un script incorrecto podría usarlo como un túnel hacia la intranet.Regla de oro
Imagine lo que vería un usuario si accediera al recurso en una ventana de incógnito. Si está contento con que todos vean este contenido (incluido el código fuente que recibió el navegador), es seguro agregarlo
Access-Control-Allow-Origin: *.fuente
Access-Control-Allow-Origin: *solo permite solicitudes sin cookies. He editado la respuesta para aclarar un poco.AFAIK, Access-Control-Allow-Origin es solo un encabezado http enviado desde el servidor al navegador. Limitarlo a una dirección específica (o deshabilitarlo) no hace que su sitio sea más seguro, por ejemplo, para los robots. Si los robots lo desean, pueden ignorar el encabezado. Los navegadores habituales (Explorer, Chrome, etc.) cumplen el encabezado de forma predeterminada. Pero una aplicación como Postman simplemente lo ignora.
El servidor no verifica realmente cuál es el 'origen' de la solicitud cuando devuelve la respuesta. Simplemente agrega el encabezado http. Es el navegador (el cliente final) el que envió la solicitud que decide leer el encabezado de control de acceso y actuar sobre él. Tenga en cuenta que en el caso de XHR puede usar una solicitud especial de 'OPCIONES' para pedir primero los encabezados.
Por lo tanto, cualquier persona con capacidades creativas de secuencias de comandos puede ignorar fácilmente todo el encabezado, lo que esté configurado en él.
Consulte también Posibles problemas de seguridad al configurar Access-Control-Allow-Origin .
Ahora para responder realmente la pregunta
Si alguien quiere atacarte, puede pasar fácilmente por Access-Control-Allow-Origin. Pero al habilitar '*', le da al atacante algunos 'vectores de ataque' más para jugar, por ejemplo, utilizando navegadores web regulares que respetan ese encabezado HTTP.
fuente
Access-Control-Allow-Origin *se desaconseja configurar un sitio web malicioso que aloje scripts para robar contraseñas :-)192.168.1.1) y reconfigurar su enrutador para permitir ataques. Incluso puede usar su enrutador directamente como un nodo DDoS. (La mayoría de los enrutadores tienen páginas de prueba que permiten pings o verificaciones simples del servidor HTTP. Se puede abusar de ellas en masa).Aquí hay 2 ejemplos publicados como comentarios, cuando un comodín es realmente problemático:
- Brad
- Brad
Siento que estos comentarios deberían haber sido respuestas, porque explican el problema con un ejemplo de la vida real.
fuente
En un escenario en el que el servidor intenta deshabilitar el CORS por completo, configura los siguientes encabezados.
Access-Control-Allow-Origin: * (le dice al navegador que el servidor acepta solicitudes de sitios cruzados de cualquier ORIGEN)
Access-Control-Allow-Credentials: verdadero (le dice al navegador que las solicitudes de sitios cruzados pueden enviar cookies)
Hay un sistema a prueba de fallos implementado en los navegadores que generará el siguiente error
Entonces, en la mayoría de los escenarios, configurar 'Access-Control-Allow-Origin'
*no será un problema. Sin embargo, para protegerse contra ataques, el servidor puede mantener una lista de orígenes permitidos y cada vez que el servidor recibe una solicitud de origen cruzado, puede validar el encabezado ORIGIN contra la lista de orígenes permitidos y luego repetir el mismo en Access-Control-Allow-Origin encabezamiento.Dado que el encabezado ORIGIN no se puede cambiar con JavaScript que se ejecuta en el navegador, el sitio malicioso no podrá falsificarlo.
fuente