Certificado SSL/TLS y HTTPS: qué protege cada capa, de HSTS a CSP y las cookies

1. Entiende el papel del certificado en una visita

Cuando un navegador se conecta por HTTPS, TLS establece la comunicación cifrada. El navegador comprueba que el certificado cubre el nombre solicitado, que está dentro de su periodo de validez y que se puede construir una cadena hasta una autoridad de confianza. En cuanto al protocolo, la guía TLS de OWASP indica que las aplicaciones web deben usar TLS 1.3 por defecto y pueden admitir TLS 1.2 por compatibilidad, mientras que TLS 1.0, TLS 1.1, SSLv2 y SSLv3 deben estar desactivados. Anotar qué protocolo se negoció en una conexión concreta da un dato verificable, aunque no dice qué otras versiones acepta el servidor.

Haz una lista de los nombres públicos: el dominio principal, www y los subdominios de servicios. Comprueba cada uno y anota qué proveedor gestiona su certificado. La CDN y el servidor de origen pueden tener certificados distintos con renovaciones distintas, y OWASP aconseja mantener una lista de los sistemas que comparten un mismo certificado para poder actualizarlos todos si caduca o se ve comprometido.

Las renovaciones van a ser cada vez más frecuentes. Según el calendario aprobado por el CA/Browser Forum, los certificados públicos emitidos desde el 15 de marzo de 2026 duran como máximo 200 días; desde el 15 de marzo de 2027, 100 días, y desde el 15 de marzo de 2029, 47 días. Let's Encrypt dejó de enviar avisos de caducidad por correo en junio de 2025 y recomienda renovar con ARI (ACME Renewal Information) o hacia los dos tercios de la vida del certificado, no con un intervalo fijo. Automatiza la renovación y vigila la caducidad con una herramienta independiente.

2. Observa cómo se complementan las capas

Piensa en estos controles como instrucciones complementarias: el certificado protege la conexión y las cabeceras describen cómo debe comportarse cada respuesta. Un artículo público, la página de una cuenta y un widget pensado para insertarse en otros sitios tienen funciones distintas y necesitan políticas que reflejen esa función. Además, algunas cabeceras solo tienen sentido donde el navegador muestra algo: según la guía de OWASP, en la respuesta JSON de una API una CSP o X-Frame-Options aportan poco.

3. Construye la CSP a partir de los recursos que usa la gente

Content-Security-Policy (CSP) indica al navegador desde dónde puede cargar una página scripts, estilos, imágenes, fuentes, conexiones y marcos. Su uso principal es reducir el impacto del cross-site scripting (XSS), y la guía de CSP de MDN recuerda que no sustituye al saneamiento de los datos de entrada. Empieza con un inventario de recursos y recorre el trayecto completo, porque el pago, la autenticación y el chat de soporte suelen cargar recursos solo después de una interacción.

Prueba la política con la cabecera Content-Security-Policy-Report-Only, que informa de las infracciones sin bloquear nada y puede convivir con una política ya aplicada. Revisa la consola del navegador o el destino de informes configurado, asocia cada aviso a su recurso y decide la regla. Cuando hayas revisado recorridos representativos, aplica la política probada.

Para los scripts, MDN recomienda una «CSP estricta» basada en nonces o hashes en lugar de una larga lista de dominios permitidos, y evitar 'unsafe-inline', que anula buena parte de la protección. Con scripts de terceros que cargan otros scripts es más difícil de aplicar, así que anótalos aparte en el inventario. Ten en cuenta también que una política de solo informe y la directiva frame-ancestors no funcionan dentro de una etiqueta <meta>: tienen que enviarse como cabecera HTTP. Un inventario documentado facilita evaluar futuras incorporaciones y explica el motivo de cada permiso.

4. Convierte HTTPS en un hábito del navegador

HSTS (Strict-Transport-Security) indica al navegador que use solo HTTPS para un host durante los segundos fijados en max-age y que convierta a HTTPS cualquier intento posterior por HTTP. El navegador aprende la política de una respuesta HTTPS válida e ignora la cabecera si llega por HTTP sin cifrar, así que la redirección de HTTP a HTTPS no debe llevarla: la que cuenta es la respuesta HTTPS. HSTS no protege la primera visita, solo las siguientes.

Tiene un efecto que conviene planificar: en un host con HSTS, el navegador no deja al visitante saltarse un error de certificado, de modo que un certificado caducado deja fuera a quien ya conocía el sitio hasta que se renueve. Empieza con una duración que tu equipo pueda revisar con comodidad y amplíala por etapas; hstspreload.org propone subir de cinco minutos a una semana y después a un mes, comprobando en cada paso que nada se rompe.

La opción includeSubDomains extiende la política a todos los subdominios, así que contrástala con tu inventario de nombres; aun así, cada subdominio debería enviar su propia cabecera. La precarga (preload) añade el dominio a una lista integrada en los navegadores para cubrir también la primera visita. Trátala como una decisión de largo plazo: hstspreload.org recomienda HSTS, pero ya no recomienda la precarga, porque Chrome y Safari convierten las navegaciones a HTTPS de todos modos, y salir de la lista lleva meses. La guía de cabeceras de OWASP todavía incluye preload en el valor que recomienda, así que conviene leer ambas fuentes antes de decidir. La referencia de HSTS en MDN explica cómo se combinan estas opciones.

5. Adapta las cookies y las demás cabeceras al recorrido

Una cookie de sesión permite al servicio reconocer una visita que continúa. Según la referencia de Set-Cookie en MDN, cada atributo resuelve una cuestión distinta:

• Secure: el navegador solo envía la cookie por HTTPS (salvo en localhost). No la oculta de JavaScript.
• HttpOnly: impide que el JavaScript de la página lea la cookie, por ejemplo con document.cookie. No la cifra ni evita que se envíe: el navegador la sigue adjuntando a cada solicitud que corresponde, incluidas las que lanza el propio JavaScript con fetch(). Limita el robo de la cookie mediante XSS, pero no evita el XSS.
• SameSite: controla si la cookie viaja en solicitudes entre sitios (Strict, Lax o None). Algunos navegadores aplican Lax si no se indica nada, así que conviene fijarlo de forma explícita; None exige también Secure. OWASP lo trata como una defensa adicional contra CSRF, no como sustituto del token CSRF.

Elige los valores pensando en el inicio de sesión y en los retornos desde servicios externos: con SameSite=Strict, la cookie no se envía cuando el visitante vuelve desde la pasarela de pago, porque esa solicitud se origina en otro sitio.

Otras cabeceras completan el tratamiento del contenido. X-Content-Type-Options: nosniff hace que el navegador bloquee scripts y hojas de estilo servidos con un tipo MIME incorrecto y deje de adivinar el tipo del resto, así que Content-Type tiene que ser correcto en todo el sitio. Referrer-Policy decide cuánta información de la URL viaja en la cabecera Referer; sin ella, los navegadores aplican strict-origin-when-cross-origin, aunque OWASP aconseja enviarla igualmente. Para decidir quién puede insertar la página en un marco, usa la directiva frame-ancestors, que no hereda de default-src, y deja X-Frame-Options: DENY o SAMEORIGIN como respaldo para navegadores antiguos; con ALLOW-FROM, los navegadores actuales ignoran toda la cabecera. X-XSS-Protection está obsoleta: no la envíes o ponla a 0. La guía de cabeceras de OWASP ayuda a elegir los valores; anota el propósito de cada cabecera para que la aplicación, el proxy y la CDN expresen una política coherente. Un fallo frecuente en nginx: add_header sin always solo añade la cabecera con algunos códigos de estado, y las páginas de error se quedan sin ella.

6. Comprueba la experiencia terminada

Abre la pestaña de red de las herramientas para desarrolladores del navegador, carga la página y sigue las redirecciones hasta la respuesta final. Revisa el certificado, las cabeceras y las cookies que llegan realmente. Así relacionas la configuración con la experiencia del visitante y ves qué servicio aporta cada ajuste: una cabecera puede venir de la aplicación, otra de la CDN y otra del proxy. Para revisar las cabeceras una por una con DevTools o curl, con valores seguros para empezar, consulta la guía para comprobar las cabeceras de seguridad HTTP.

1. Visita por HTTPS los nombres públicos de tu lista y prueba también su versión http://: según la guía de configuración TLS de MDN, debería redirigir al mismo recurso en HTTPS. Usa una redirección permanente, por ejemplo un 301.
2. Anota los datos del certificado (nombres, emisor y caducidad) y las cabeceras de la respuesta final.
3. Completa el inicio de sesión, la recuperación de cuenta, el pago integrado y los retornos desde servicios externos.
4. Revisa los avisos de la consola y el destino de informes CSP que hayas elegido.

Guarda un registro fechado de la configuración y de quién gestiona cada capa. Cuando cambie el alojamiento o una integración, repite el mismo recorrido para confirmar el comportamiento previsto. Un despliegue planificado, con la configuración anterior a mano, facilita coordinar los cambios, y la lista resultante sirve como introducción práctica para quien mantenga el sitio en el futuro.

Para revisar ahora las cabeceras de un sitio, usa el comprobador de cabeceras de seguridad HTTP gratuito.

7. Mantén el mapa de protección cerca del sitio

Reúne en un solo lugar los nombres públicos, los responsables de los certificados, los recursos que carga el navegador y los recorridos importantes. Para una lectura rápida desde fuera, el snapshot gratuito de Sitelemetry ejecuta ocho comprobaciones pasivas sobre un origen público, sin crear una cuenta, entre ellas el certificado TLS y las cabeceras de seguridad HTTP. No es un pentest. Su alcance es concreto: hace una única negociación TLS (handshake) y comprueba que la cadena sea de confianza, que el certificado no caduque en los próximos 30 días y que el protocolo negociado sea TLS 1.2 o 1.3, sin enumerar versiones ni cifrados. En la respuesta final, tras seguir hasta cinco redirecciones, comprueba sobre todo si las cabeceras están presentes y si las cookies llevan HttpOnly y Secure; no revisa SameSite. La redirección de HTTP a HTTPS solo se prueba si escribes la dirección con http://, y en ese caso se omite la comprobación del certificado.

La guía de auditoría de seguridad web explica cómo se conectan estas capas con las cuentas, los permisos y el mantenimiento diario.