security cors

security - ¿Es seguro habilitar CORS a*para un servicio web público y de solo lectura?



(2)

Habilitar CORS tiene varios problemas de seguridad :

  • CSRF
  • exposición de datos protegidos

Pero, ¿hay algún problema para un servicio web público y de solo lectura para habilitar CORS global?

Access-Control-Allow-Origin: *

Mis suposiciones:

  • CSRF no es relevante, porque el servicio web es de solo lectura.
  • el robo de datos protegidos no es relevante porque el servicio web es público.

Aquí hay algo relevante de la especificación Fetch (que define CORS):

Configuración básica segura del protocolo CORS

Para los recursos en los que los datos están protegidos a través de la autenticación de IP o un firewall (desafortunadamente relativamente común), el uso del protocolo CORS no es seguro. (Esta es la razón por la cual el protocolo CORS tuvo que ser inventado).

Sin embargo, de lo contrario, usar el siguiente encabezado es seguro:

Access-Control-Allow-Origin: *

Incluso si un recurso expone información adicional basada en cookies o autenticación HTTP, el uso del encabezado anterior no lo revelará. Compartirá el recurso con API como XMLHttpRequest , al igual que ya se comparte con curl y wget .

En otras palabras, si no se puede acceder a un recurso desde un dispositivo aleatorio conectado a la web mediante curl y wget no se incluirá el encabezado mencionado anteriormente. Sin embargo, si se puede acceder, está perfectamente bien hacerlo.

Y el autor de la especificación Fetch / CORS entra en un poco más de detalle en una publicación de blog relacionada :

Es completamente seguro aumentar cualquier recurso con Access-Control-Allow-Origin: * siempre y cuando el recurso no sea parte de una intranet (detrás de un firewall). En otras palabras, una URL que puede obtener de un servidor en Internet usando wget o curl . Para su sitio web básico, esto abarca todos los recursos del sitio. El encabezado Access-Control-Allow-Origin (parte de CORS) le dice al navegador que el recurso se puede compartir.

Incluso si el recurso incluye información confidencial basada en cookies o datos de autenticación HTTP en la solicitud, incluido el encabezado y compartir el recurso sigue siendo seguro, ya que el navegador realizará la solicitud sin cookies ni datos de autenticación HTTP. Y si el navegador realizó la solicitud con cookies o datos de autenticación HTTP, nunca compartiría el recurso porque eso requeriría un encabezado adicional, Access-Control-Allow-Credentials y un valor diferente para el encabezado mencionado anteriormente.

¡Así que adelante y comparta con seguridad sus datos públicos con otras aplicaciones!


Si es una API pública, CORS debería estar habilitado para todas las solicitudes. Uno de los mejores enfoques de seguridad para las API públicas es usar claves de aplicación en los encabezados de solicitud.