Cookies seguras y HSTS: guía de configuración completa

📅 Publicado el 23 de octubre, 2026 · Por Equipo RedServicio

Si gestionas una tienda online, un panel de administración o, simplemente, un blog con inicio de sesión, hay dos cosas que no puedes dejar al azar: las cookies seguras y HSTS. Protegen frente a interceptaciones, secuestros de sesión y ataques de downgrade. Y no, no es opcional. En esta primera parte de la guía te explico qué son, por qué importan y cómo empezar a implementarlos, con ejemplos concretos.

¿Qué son las cookies seguras y HSTS y por qué importan?

Las cookies son pequeños archivos que el servidor envía al navegador del usuario para guardar información de sesión, preferencias o datos de autenticación. El problema aparece cuando viajan sin protección. Imagina alguien conectado a la WiFi de un aeropuerto: si un atacante intercepta ese tráfico, puede robar la cookie de sesión y suplantar al usuario. Es el clásico session hijacking. Ocurre más de lo que la gente cree.

Una cookie segura es la que incluye atributos de protección como Secure, HttpOnly y SameSite, que limitan cuándo y cómo el navegador la envía, y quién puede tocarla desde el código.

HSTS (HTTP Strict Transport Security), por su parte, es una cabecera que le dice al navegador que solo debe comunicarse con tu dominio mediante HTTPS durante un período determinado. Con esto eliminas los ataques de downgrade (donde el atacante fuerza una conexión insegura) y previenes otro fallo muy común: que el usuario escriba «midominio.com» a mano y acceda por HTTP antes de que salte la redirección. Ese instante, breve, es suficiente para un atacante.

Juntos, estos mecanismos forman la base de la seguridad a nivel de transporte y sesión. Los principales navegadores penalizan cada vez más los sitios que no los implementan, y estándares como PCI DSS los exigen para el comercio electrónico. No hay mucho margen de discusión aquí.

Cómo configurar cookies con los flags Secure, HttpOnly y SameSite

Estos son los tres atributos esenciales que deberías aplicar a cada cookie de sesión:

• Secure: la cookie solo se envía por conexiones HTTPS cifradas. Nunca por HTTP plano.
• HttpOnly: impide que JavaScript acceda a la cookie mediante document.cookie. Esto mitiga los ataques XSS que intentan robar sesiones.
• SameSite: controla si la cookie se envía en peticiones de sitios externos. Valores posibles: Strict (nunca en peticiones cruzadas), Lax (solo en navegaciones de nivel superior, valor por defecto en navegadores modernos) y None (siempre, pero exige el flag Secure).

Una configuración razonable para una cookie de sesión sería:

Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Lax; Path=/; Max-Age=3600

Algunos consejos prácticos que me han ahorrado más de un quebradero de cabeza:

1. Usa SameSite=Lax por defecto para sesiones de usuario; reserva Strict para acciones sensibles como pagos.
2. Evita SameSite=None salvo que necesites cookies en contextos de terceros (iframes, pasarelas de pago embebidas).
3. Combina las cookies con HSTS. Sin HTTPS garantizado, el flag Secure pierde buena parte de su sentido.

Ejemplos prácticos: cookies seguras en PHP, JavaScript y Nginx

Configuración en PHP

En PHP, lo más limpio es usar la función setcookie() con el array de opciones (disponible desde PHP 7.3):

setcookie(‘sessionId’, $valor, [
‘secure’ => true,
‘httponly’ => true,
‘samesite’ => ‘Lax’,
‘path’ => ‘/’,
‘max-age’ => 3600
]);

También puedes configurarlo globalmente en el archivo php.ini:

• session.cookie_secure = 1
• session.cookie_httponly = 1
• session.cookie_samesite = Lax

Configuración en JavaScript (creación en cliente)

Cuando creas cookies desde el navegador, la sintaxis es la misma cadena de atributos:

document.cookie = «preferencia=oscuro; Secure; SameSite=Lax; Max-Age=86400; path=/»;

Ojo con esto: las cookies con HttpOnly no pueden crearse ni leerse desde JavaScript. Y eso es exactamente lo que se busca. Están reservadas para datos sensibles que gestiona el servidor.

Configuración en Nginx

A nivel de servidor puedes forzar los flags en todas las cookies de respuesta y activar HSTS en el bloque server de tu configuración:

• add_header Set-Cookie «Path=/; Secure; HttpOnly; SameSite=Lax»;
• add_header Strict-Transport-Security «max-age=31536000; includeSubDomains» always;

Ese max-age=31536000 le dice al navegador que recuerde la política durante un año. Mi recomendación: empieza con un valor bajo (300 segundos, por ejemplo) para probar, y amplíalo solo cuando verifiques que todo tu sitio funciona correctamente bajo HTTPS. Subirlo a un año y descubrir luego que un subdominio se ha roto es un dolor evitable.

Con estas bases ya aplicadas en tu servidor, en la siguiente parte de la guía profundizaremos en la configuración avanzada de HSTS, la precarga en navegadores y cómo auditar tu sitio para verificar que todo funciona como debe.

Qué es la cabecera Strict-Transport-Security (HSTS) y cómo activarla

La cabecera Strict-Transport-Security (HSTS) le dice al navegador que solo debe hablar con tu sitio mediante HTTPS. Aunque el usuario escriba «http://» a mano, aunque llegue desde un enlace sin cifrar. ¿Por qué importa esto? Porque durante esa primera redirección existe una pequeña ventana en la que un atacante podría interceptar la petición. HSTS la cierra.

Activarla es sencillo. Se trata de añadir una línea en la respuesta del servidor. En Apache (en el .htaccess o en la configuración del virtual host) y en Nginx queda así:

• Apache: Header always set Strict-Transport-Security «max-age=31536000; includeSubDomains; preload»
• Nginx: add_header Strict-Transport-Security «max-age=31536000; includeSubDomains; preload» always;

Cada directiva hace una cosa distinta. max-age marca cuánto tiempo —en segundos— recuerda el navegador la política; 31536000 es un año entero. includeSubDomains extiende la protección a todos los subdominios. Y preload habilita tu sitio para entrar en la lista de precarga de los navegadores, que fuerza HTTPS desde la primera visita, sin esperar a ninguna redirección.

Errores comunes al configurar cookies seguras y HSTS

Aunque lleves años administrando servidores, estos errores se cuelan. Los he visto todos, alguna vez en mi propia configuración:

1. Activar preload sin includeSubDomains: la política de precarga exige ambos parámetros. Sin ellos, hstspreload.org rechazará tu solicitud sin más.
2. Dejar subdominios en HTTP: si activas includeSubDomains pero algún subdominio —un panel antiguo, una API interna, quien sabe— no tiene certificado válido, dejará de funcionar para tus visitantes. Audita todo antes de aplicarlo. Todo.
3. Cookies sin el atributo Secure tras activar HSTS: HSTS cifra la conexión, sí, pero una cookie sin Secure puede seguir enviándose en contextos no seguros. Configura siempre Secure; HttpOnly; SameSite=Lax en cada cookie.
4. Contenido mixto sin corregir: imágenes, scripts o CSS servidos por HTTP romperán la experiencia, o el navegador los bloqueará directamente. El inspector de tu navegador los localiza en minutos.
5. Max-age excesivo sin pruebas previas: configuras un año, y dos semanas después descubres que un servicio se ha roto. Los usuarios afectados no podrán volver hasta que la política expire en su navegador. Un año es mucho tiempo.

Conclusiones: cookies seguras y HSTS para una web protegida

La combinación de cookies seguras y HSTS es la base de una web cifrada de verdad. No de un sitio «con candado», que es distinto. Las cookies marcadas con Secure, HttpOnly y SameSite protegen los datos de sesión de tus usuarios; la cabecera Strict-Transport-Security garantiza que toda la comunicación vaya siempre por HTTPS, cerrando la puerta a ataques de downgrade e interceptación.

La clave, como en casi todo, está en ir por partes. Corrige primero el contenido mixto. Aplica HSTS con un max-age corto. Valida todos tus subdominios. Y solo entonces sube al plazo máximo y solicita la precarga. Un hosting de calidad con soporte 24/7, como el que ofrecemos en RedServicio, facilita mucho el proceso: cabeceras, certificados SSL gratuitos y configuraciones del servidor, todo gestionable sin dolores de cabeza técnicos.

Dedica una hora hoy a revisar estos puntos en tu sitio. Tus usuarios lo agradecerán. Y tu posicionamiento en buscadores también.