Hay dos formas de configurar el indicador 'seguro' en una cookie de sesión:
En la propia aplicación, por ejemplo:
<session-config>
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>
</session-config>
En la configuración del proxy TLS como httpd.
No puedo encontrar ningún artículo que indique cuál es la mejor práctica.
El más seguro es probable que sea 2, mientras que el más lógico es el 1, ya que solo funciona con HTTPS.
En la aplicación.
Las cookies son establecidas por la aplicación, y las marcas de cookies son parte de eso. Las cookies pueden tener varias marcas: "seguro", "httponer", "samesite". Sólo la aplicación sabe qué cookies deben tener qué marcas. Si su proxy inserta el indicador httponly y la aplicación quiere acceder a la cookie con Javascript, esto ya no funcionará. Las cookies son responsabilidad de la aplicación.
Además, desea que la aplicación se comporte de manera consistente sin importar qué proxy esté usando. Es probable que los desarrolladores no utilicen ningún proxy al probar la aplicación, pero aún así deben usar cookies seguras para que el entorno coincida con la producción.
Recomiendo que sea mejor usar los dos juntos ya que no causa ningún daño. Además, garantiza la filosofía de Defensa en profundidad .
En estos días, las personas se están implementando en la nube y las migraciones se realizan con más frecuencia. Por lo tanto, creo que no podemos estar seguros de que la configuración 2 que mencionó para httpd esté en su lugar todo el tiempo.
Debes considerar que habilitar <secure>true</secure> en la aplicación es obligatorio. Explicación dada a continuación.
Explicación :
Escenario 1 (Suponiendo que el proxy TLS / httpd no supere la configuración de seguridad)
Probé un escenario en el que solo habilité <secure>true</secure> en la aplicación y no configuré el indicador de seguridad a través del proxy TLS (httpd).
Ahora, el encabezado de respuesta tiene una cookie con marca segura, observé que Firefox y Chrome se procesan y guardan la cookie con marca segura.
Set-Cookie: acct=tafats; domain=localhost; Secure;expires=Thu, 16-Mar-2017 15:19:48 GMT; path=/; HttpOnly
Desde un punto de vista de seguridad, esto es lo que se espera de los navegadores.
Esto lo protege de los intentos de secuestro de sesión a través del rastreo de paquetes.
En este caso, si el atacante hace que el usuario haga clic en http://example.com , la cookie no se envía porque tiene una marca segura.
Aquí, <secure>true</secure> vino a rescatar.
Escenario 2 (Suponiendo que la configuración del indicador de seguridad se haya perdido en la aplicación pero se haya configurado en el proxy / httpd de TLS)
Suficientemente bueno, siempre y cuando tenga este indicador de seguridad establecido a través del proxy TLS. Pero el problema aquí es que debe asegurarse de que esta configuración de proxy TLS esté configurada para todas las implementaciones que realice todo el tiempo.
Para concluir, recomiendo que sea mejor usar los dos juntos y Asegurar la filosofía de la defensa en profundidad.
Lea otras preguntas en las etiquetas cookies session-management