Cookies con prefijo y CORS

Los atributos Secure, HttpOnly y SameSite los pone quien emite la cookie, pero un navegador no puede saber si otro subdominio, con un fallo propio, la sobrescribió. Los prefijos son la forma de pedirle al navegador que lo imponga: el prefijo __Secure- obliga a Secure; el prefijo __Host- exige además que no lleve atributo Domain y que su Path sea /. Una cookie con __Host- queda atada al host exacto que la emitió: no viaja a los subdominios ni la puede fijar uno de ellos.

Una cookie de sesión con Domain= del dominio padre viaja a todos los subdominios, incluidos los viejos y mal mantenidos. Eso no es un fallo por sí solo, pero amplía a quién le llega.

SameSite controla si la cookie viaja en peticiones que vienen de otros sitios. Con Lax viaja en navegaciones normales y no en peticiones incrustadas; con Strict, solo dentro del mismo sitio. SameSite=None la deja viajar en todos los contextos y, por eso, los navegadores exigen que vaya junto con Secure; sin él, la cookie se rechaza o queda sin efecto. Una cookie con esa combinación mal puesta es un descuido de configuración, y se pide corregirla o, si no hace falta que viaje entre sitios, usar Lax.

Abre set-cookie-tienda.txt y revisa los tres Set-Cookie.

Por defecto, el navegador impide que una página de un origen lea la respuesta de otro (política del mismo origen). CORS es la excepción que la API autoriza con la cabecera Access-Control-Allow-Origin, y es la API quien decide a quién se lo permite. CORS no protege a la API de que le llegue una petición: protege los datos del usuario frente a páginas ajenas que quieran leer la respuesta.

Dos reglas mandan. Con credenciales (cookies), el valor no puede ser el comodín *: el navegador bloquea la respuesta y exige un origen concreto. Y si el servidor elige el origen según la petición, debe añadir Vary: Origin, para que las cachés no mezclen respuestas. El error peligroso no es el comodín (el navegador lo frena con credenciales), es el servidor que refleja cualquier origen y además permite credenciales: entonces cualquier sitio puede leer datos de un usuario con la sesión abierta.

La lista de orígenes permitidos es una decisión del equipo: aquí son dos, la tienda y el panel. Todo lo demás con credenciales es un hallazgo. Se lee en las respuestas guardadas, comparando origen pedido y origen permitido, y se contrasta con la lista.

Abre origenes-permitidos.txt y cors-api.txt. En cuatro casos de la revisión hay uno que la API acepta con credenciales y que no debería.

No toda configuración de CORS es un hallazgo. El caso 4 responde con un comodín a datos públicos del catálogo, sin cookies: es lo que se espera de un recurso público. El caso 3 acepta el origen especial null con credenciales, que puede venir de documentos locales o marcos aislados, y también se anota. Y la cookie sin Secure es un descuido de configuración, bastante menor que lo que hace el caso 2.

El informe ordena por lo que un tercero puede hacer con los datos reales de un usuario real.