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 concurl
ywget
.En otras palabras, si no se puede acceder a un recurso desde un dispositivo aleatorio conectado a la web mediante
curl
ywget
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 usandowget
ocurl
. Para su sitio web básico, esto abarca todos los recursos del sitio. El encabezadoAccess-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.