Los desarrolladores no entienden CORS (2019)

Artículo original ↗ Discusión en Hacker News ↗

Sentimiento general

  • Muchos participantes admiten que en realidad no entienden CORS, incluso desarrolladores web con experiencia.
  • El propio hilo de comentarios se cita como evidencia de que el ecosistema está profundamente confundido sobre CORS y su modelo de amenazas.

Política del mismo origen vs CORS

  • Varios comentarios subrayan que el mecanismo de seguridad الأساسي es la Same-Origin Policy (SOP); CORS es una forma de relajarla de manera selectiva.
  • Aclaración clave: normalmente el navegador bloquea la lectura de respuestas de otros orígenes, no el envío de solicitudes; CORS permite algunas lecturas entre orígenes cuando el servidor lo autoriza.

Modelo de amenazas y qué protege realmente CORS

  • Se describe CORS como una protección para el usuario en un navegador frente a sitios de terceros maliciosos, no como una protección del backend frente a clientes HTTP genéricos.
  • Escenario típico: el usuario ha iniciado sesión en el sitio A (hay cookies configuradas), luego visita el sitio B malicioso que intenta leer datos privados o actuar en su nombre contra A.
  • Varios comentarios señalan solapamiento y confusión con las protecciones CSRF; algunos las mezclan, otros insisten en que CSRF debe seguir tratándose por separado.

Preflight, solicitudes “simples” y casos límite

  • Muchos problemas de CORS surgen de la distinción entre:
    • Solicitudes “simples” (GET, algunos POST con tipos de contenido específicos) que omiten el preflight.
    • Solicitudes “no simples” (por ejemplo, POST JSON, cabeceras personalizadas) que requieren un preflight OPTIONS y aprobación explícita de CORS.
  • Los ejemplos muestran cómo una comprobación laxa de Content-Type (por ejemplo, aceptar JSON en text/plain o en codificaciones de formulario) puede eludir supuestos basados en el preflight.
  • Los comentaristas enfatizan que un comportamiento potencialmente destructivo no debe exponerse mediante métodos “seguros” o simples como GET.

Uso indebido y conceptos erróneos

  • Patrón común: los desarrolladores “simplemente ponen Access-Control-Allow-Origin: *” para que funcione, ignorando las implicaciones de seguridad.
  • Algunos creen erróneamente que CORS puede impedir que otros sitios o scrapers llamen a una API en absoluto; otros corrigen que los clientes que no usan navegador o que tienen CORS desactivado no se ven afectados.
  • El ejemplo de Zoom con localhost se considera engañoso: las cabeceras CORS no habrían “restringido” por completo el acceso como se sugiere.

Experiencia del desarrollador y aprendizaje

  • Depurar se describe como doloroso: los mensajes de error del navegador son opacos, las vistas de las herramientas de desarrollo son confusas y la causa real (las cabeceras del servidor) queda oculta.
  • Muchos ven CORS como algo de “configurar y olvidar”; lo vuelven a aprender cada vez y luego lo olvidan.
  • Algunos recomiendan la documentación de CORS en MDN y entender primero SOP; otros sostienen que la especificación y la documentación son demasiado complejas y, por tanto, el protocolo es efectivamente “malo”.

Arquitectura y alternativas

  • Una postura: lo mejor es alojar frontend y backend en el mismo origen (mediante un proxy inverso) y evitar CORS por completo.
  • Contraargumento: las arquitecturas del mundo real a menudo requieren orígenes separados, así que entender y configurar CORS sigue siendo necesario.