Configurando cookies en el cuerpo
No puede configurar cookies en el cuerpo de la respuesta (los navegadores no buscan cookies), ni su navegador puede Presentar las cookies en el cuerpo de la solicitud (el servidor no buscará allí). Por definición, las cookies se publican en el encabezado HTTP (consulte RFC 6265 ).
Poner datos seguros en el cuerpo
Ciertamente, puede enviar otros datos de sesión o tokens en el cuerpo de la solicitud o respuesta (por ejemplo, es común pasar un "token CSRF en el cuerpo), pero si lo hace, no son cookies. Si esta es una buena idea es una pregunta diferente.
La mayoría de los datos están bien en el cuerpo, después de todo, esa es la única parte que el usuario puede ver y, a veces, el usuario debe mostrar datos confidenciales.
Sin embargo, algunos datos no están bien en el cuerpo. Todo lo que desee que no esté disponible para un ataque XSS, por ejemplo, no debe estar en el cuerpo, y solo debe estar contenido en un Cookie de solo HTTP para que no se pueda leer desde DOM .
Dicho esto, ¡algunos datos están mejor en el cuerpo! Por ejemplo, cualquier cosa que no desee que aparezca en los registros de IIS predeterminados se debe colocar en el cuerpo. Todo lo que no desee que se incluya en una sesión de solicitud falsificada (a.k.a. CSRF) debe incluirse en el cuerpo y no como una cookie.
Configuración de datos en ambos
No es necesariamente un problema de seguridad establecer un token tanto en una cookie como en el cuerpo. De hecho, este es exactamente el patrón requerido por el Double Submit Cookie CSRF mitigation .
Por otro lado, si solo está pasando el ID de sesión en el cuerpo por completo, y es un duplicado de un HttpOnly cookie , entonces acaba de anular cualquier beneficio de usar la bandera HttpOnly, ya que el mismo valor puede leerse desde el DOM.
También, aquí hay algo realmente divertido: si el sitio establece una cookie HttpOnly desde el lado del servidor, y el mismo valor de la cookie se pasa a través del cuerpo de la página y se establece a través del script del cliente, su navegador terminará con dos cookies con el mismo ¡nombre! Esta condición debe evitarse porque no hay ninguna especificación HTTP que indique qué cookie se debe presentar en este caso, y el comportamiento del navegador variará.