Cloudflare: cabeceras de seguridad, HSTS, HTTPS y caché sin romper tu web

Para configurar bien Cloudflare, pon el cifrado en Full (strict), activa Always Use HTTPS y HSTS empezando por un max-age corto, y añade las cabeceras de seguridad con una regla de transformación de respuesta, no con el interruptor gestionado, que aún envía X-XSS-Protection y Expect-CT. El HTML no se cachea salvo que crees una Cache Rule.

Para comprobarlo en tu web: Auditoría SEO

Cloudflare se coloca entre el visitante y tu servidor (el «origen»), así que puede añadir HTTPS, cabeceras y caché sin tocar la configuración del servidor. Es cómodo, pero tiene trampas: un modo de cifrado que no cifra todo el camino, un botón de cabeceras que trae dos obsoletas y una caché que, por defecto, no guarda tus páginas. Esta guía sigue la documentación oficial de Cloudflare consultada el 07-10-2026.

¿Qué hace Cloudflare y qué sigue haciendo tu servidor?

Si prefieres hacerlo en el servidor, tienes las guías de HTTPS, HSTS y cabeceras para Apache con .htaccess y para Nginx. La otra mitad de Cloudflare, qué rastreadores de IA dejas entrar, está en la guía de bots de IA en Cloudflare.

Paso 1: el modo de cifrado, Full (strict) y nunca Flexible

El modo de cifrado SSL/TLS decide cómo se cifran las dos conexiones: la del visitante con Cloudflare y la de Cloudflare con tu servidor. Se cambia en SSL/TLS > Overview1. Las opciones manuales son estas:

Por qué Flexible es mala idea si tu origen ya tiene HTTPS. El tramo entre Cloudflare y tu servidor viaja en claro, y si tu servidor redirige HTTP a HTTPS, Cloudflare le pide por HTTP, el servidor le devuelve una redirección a HTTPS, Cloudflare vuelve a pedir por HTTP… y la web queda inaccesible por un bucle de redirecciones. Cloudflare lo dice expresamente: no uses Flexible si el origen fuerza HTTPS, ni si la web maneja datos personales o inicios de sesión2.

Full (strict) exige que el certificado del origen no haya caducado, que lo emita una autoridad pública o el Origin CA de Cloudflare, y que coincida con el nombre del host. Si falla, el visitante ve un error 5263.

En las zonas migradas, la opción por defecto es Automatic SSL/TLS, que sube el modo al más seguro que admite tu origen y nunca lo baja1. Si ves «Automatic», mira qué modo ha elegido en realidad.

Paso 2: Always Use HTTPS y HSTS

Always Use HTTPS redirige todas las peticiones de http a https, en todos los subdominios. Se activa en SSL/TLS > Edge Certificates, y solo aparece si el modo de cifrado no está en Off4. Cloudflare recomienda no hacer también la redirección en el servidor, para evitar bucles4. Forzar HTTPS no arregla el contenido mixto (imágenes o scripts cargados por http://): eso lo cubre en parte Automatic HTTPS Rewrites4.

HSTS (HTTP Strict Transport Security) es una cabecera que le dice al navegador «durante este tiempo, entra aquí solo por HTTPS». Se activa en SSL/TLS > Edge Certificates > HTTP Strict Transport Security (HSTS) > Enable HSTS5. El panel ofrece:

• Max Age: de 1 a 12 meses, o 0 para desactivar.
• includeSubDomains: aplica la política a los subdominios. Un subdominio sin HTTPS queda inaccesible.
• Preload: permite entrar en las listas de precarga de los navegadores, que exigen un max-age de 12 meses como mínimo.
• No-Sniff: añade X-Content-Type-Options: nosniff.

Los avisos de la documentación son serios5. Con HSTS activo, no pongas los registros DNS en «DNS only», no pauses Cloudflare, no cambies los servidores de nombres, no redirijas de HTTPS a HTTP y no dejes caducar el certificado: si quitas HTTPS antes de que venza el max-age, la web queda inaccesible para quien ya la visitó durante todo ese tiempo.

El orden prudente:

1. Comprueba que todos los subdominios responden por HTTPS.
2. Empieza con el max-age más corto que admita el panel (1 mes), sin includeSubDomains ni Preload. Si quieres un periodo de prueba aún más corto, Cloudflare permite enviar la cabecera con una regla de transformación de respuesta5, por ejemplo Strict-Transport-Security: max-age=86400; cuando funcione, pásate al ajuste del panel y borra la regla.
3. Sube a 12 meses y, solo entonces, valora includeSubDomains.
4. Preload es difícil de deshacer: obliga a HTTPS en todos los subdominios para todos los navegadores y salir de la lista lleva meses. Actívalo solo si lo tienes claro.

Paso 3: las cabeceras de seguridad, mejor con una regla propia

Cloudflare tiene un interruptor llamado Add security headers (en Rules > Settings > Managed Transforms)6. Hoy añade exactamente estas cinco cabeceras7:

x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN
referrer-policy: same-origin
expect-ct: max-age=86400, enforce

Dos de ellas sobran. MDN marca X-XSS-Protection como obsoleta y no estándar, avisa de que puede crear vulnerabilidades XSS en webs que eran seguras y recomienda usar Content-Security-Policy en su lugar8. Y Expect-CT también está obsoleta: solo la implementaron los navegadores basados en Chromium, que la retiraron en la versión 1079. Además, referrer-policy: same-origin no envía ninguna referencia a otros dominios, lo que puede molestarte si mides de dónde llegan los clics salientes.

Por eso es mejor crear tu propia regla de transformación de respuesta (Response Header Transform Rule)10:

1. Ve a Rules > Overview y elige Create rule > Response Header Transform Rule.
2. Ponle un nombre («Cabeceras de seguridad»).
3. En When incoming requests match, elige una expresión propia para limitarla a tu dominio: (http.host eq "www.example.com").
4. En Modify response header, elige Set static para cada cabecera. Una regla admite hasta 30 cabeceras.
5. Deploy.

Las cabeceras y valores que propongo como punto de partida:

X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Reporting-Endpoints: csp-endpoint="https://www.example.com/csp-reports"
Content-Security-Policy-Report-Only: default-src 'self'; img-src 'self' data: https:; frame-ancestors 'self'; report-to csp-endpoint

La CSP va en modo Report-Only: vigila las infracciones sin bloquear nada, y MDN la recomienda justo para probar una política antes de aplicarla11. Los informes llegan a la URL de Reporting-Endpoints, que tiene que ser un servicio tuyo que acepte peticiones POST. Cuando la lista de infracciones esté limpia, cambia el nombre de la cabecera a Content-Security-Policy.

Tres matices de la documentación12: no puedes modificar cabeceras que empiecen por cf-; cambiar Cache-Control con estas reglas no cambia cómo cachea Cloudflare; y las reglas también se aplican a las páginas de error de Cloudflare. Si usas productos de Cloudflare que inyectan scripts, como Rocket Loader o Web Analytics, tu CSP tiene que permitir sus dominios; Cloudflare publica la lista13.

Paso 4: la caché, qué guarda Cloudflare y qué no

Cloudflare cachea por extensión de fichero, no por tipo MIME, y no cachea el HTML ni el JSON por defecto14. Sí cachea, entre otras, CSS, JS, imágenes (JPG, PNG, WEBP, AVIF, SVG), fuentes (WOFF, WOFF2) y PDF. También cachea robots.txt por defecto, así que si lo cambias y no ves el cambio, purga la caché.

Tampoco cachea, aunque la extensión lo permita, si la respuesta lleva Cache-Control con private, no-store, no-cache o max-age=0, si lleva Set-Cookie o si la petición no es un GET14.

Cachear el HTML con una Cache Rule

Si tus páginas son iguales para todos los visitantes, cachear el HTML en el borde reduce el tiempo de respuesta del servidor. Se hace con una Cache Rule en Caching > Cache Rules: Cache eligibility > Eligible for cache. El plan gratuito admite 10 reglas15.

El riesgo lo explica la propia Cloudflare: esa opción cachea todo el HTML aunque tenga contenido dinámico, y un visitante puede recibir información que no era para él16. Excluye siempre lo personal. Un ejemplo para una tienda en WordPress, cuya cookie de sesión de usuario empieza por wordpress_logged_in17:

(http.host eq "www.example.com"
 and not http.request.uri.path contains "/wp-admin"
 and not http.request.uri.path contains "/carrito"
 and not http.request.uri.path contains "/mi-cuenta"
 and not http.cookie contains "wordpress_logged_in")

En Edge TTL, la opción prudente es Use cache-control header if present, use default Cloudflare caching behavior if not: tu servidor sigue mandando18. Ojo con Ignore cache-control header and use this TTL: si la respuesta trae Set-Cookie, Cloudflare la quita y guarda la página igualmente19. Ahí es donde una página con la sesión de un cliente acaba servida a otro.

Browser Cache TTL

El Browser Cache TTL fija cuánto guarda el navegador cada recurso. Por defecto son 4 horas, y Cloudflare sustituye los encabezados de tu servidor si su valor es menor o si no envía Cache-Control ni Expires20. Si tu servidor ya envía buenos encabezados (por ejemplo, un año para los CSS y JS con huella en el nombre), elige Respect Existing Headers en Caching > Configuration. Purgar la caché de Cloudflare no borra lo que ya guardó el navegador20.

Paso 5: compresión y optimizaciones que pueden romper scripts

Cloudflare comprime por defecto el HTML, CSS, JavaScript, JSON, XML, SVG y varios formatos de fuente con gzip, Brotli o Zstandard, según lo que acepte el navegador y tu plan, y solo en respuestas 200 (y en errores 403 y 404)21. Con Compression Rules puedes elegir el algoritmo por tipo de fichero; también están en el plan gratuito22. Si tu servidor envía Cache-Control: no-transform, Cloudflare no toca la compresión de esa respuesta21.

Rocket Loader retrasa la carga de todo el JavaScript hasta después de pintar la página. Cloudflare reconoce el riesgo: si ves fallos de JavaScript o jQuery, desactívalo y vuelve a probar, y si tienes CSP, añade ajax.cloudflare.com a script-src23. Pruébalo con las funciones que dependen de scripts (carrito, formularios, menú) antes de dejarlo activo.

Cómo comprobarlo

1. Cabeceras: curl -sI https://www.example.com/ y busca strict-transport-security, x-content-type-options, content-security-policy-report-only y, si activaste el interruptor gestionado, el x-xss-protection que no quieres.
2. Caché: la cabecera cf-cache-status dice si la respuesta salió de la caché (HIT), si era cacheable pero no estaba guardada (MISS), si el servidor pidió no guardarla, por ejemplo con Set-Cookie (BYPASS), o si no era cacheable (DYNAMIC)24. Pide dos veces la misma página: la segunda debería ser HIT si la Cache Rule funciona. Repite con la cookie de sesión y comprueba que deja de serlo.
3. Redirección: curl -sI http://example.com/ tiene que devolver una sola redirección a https://.
4. Puntuación externa: el HTTP Observatory de Mozilla revisa las cabeceras de seguridad, y PageSpeed Insights te dice si el tiempo de respuesta del servidor mejoró con la caché del HTML.

Qué hace SmoothSeen con esto

SmoothSeen comprueba si tu página responde por HTTPS, si redirige de http a https y qué cabeceras de seguridad envía, con el HTTP Observatory de Mozilla. También mide si el texto llega comprimido con gzip o Brotli y las Core Web Vitals de usuarios reales que publica PageSpeed Insights, con los umbrales de Google. No entra en tu cuenta de Cloudflare: ve lo que recibe un visitante, que es lo que cuenta.

Qué hacer esta semana

Abre SSL/TLS > Overview y comprueba que el modo es Full (strict). Luego mira si tienes activado «Add security headers» y sustitúyelo por una regla propia sin X-XSS-Protection ni Expect-CT. Para ver el resultado junto con la velocidad y la compresión, haz una auditoría de Posicionamiento web.

Preguntas frecuentes

¿Por qué tengo ERR_TOO_MANY_REDIRECTS al activar Cloudflare?

Casi siempre es el modo Flexible con un servidor que ya redirige a HTTPS: Cloudflare pide la página por HTTP, el servidor la manda a HTTPS y Cloudflare vuelve a pedirla por HTTP. Cambia el modo de cifrado a Full (strict) si tu servidor tiene un certificado válido, o a Full si es autofirmado mientras consigues uno válido.

¿Cloudflare añade HSTS automáticamente?

No. Hay que activarlo en SSL/TLS, Edge Certificates, y el panel exige confirmar que entiendes las consecuencias. Envía la cabecera solo en respuestas HTTPS y con el max-age que elijas, de 1 a 12 meses. Si ya la envía tu servidor, no la dupliques en Cloudflare: quédate con un único sitio para cambiarla.

¿Es buena idea cachear todo el HTML en Cloudflare?

Solo si las páginas son iguales para todos. Una web corporativa o un blog lo agradecen; una tienda con carrito y cuentas de cliente necesita excluir esas rutas y las cookies de sesión en la propia regla. Nunca fuerces el tiempo de caché ignorando los encabezados del servidor en páginas que pueden llevar la sesión de un usuario.

¿Rocket Loader mejora las Core Web Vitals?

Cloudflare dice que mejora métricas de pintado, como el primer pintado con contenido, al retrasar el JavaScript, pero su documentación no da datos sobre LCP, INP ni CLS, y avisa de que puede provocar fallos de JavaScript. Mídelo en tu web con PageSpeed Insights antes y después, revisa que el carrito y los formularios sigan funcionando y desactívalo si algo falla.