Saltar a contenido

Capítulo 25 — Integración de Firebase Hosting con Cloudflare y arquitectura de producción

Recursos visuales propuestos

Antes de desarrollar este capítulo conviene distinguir entre recursos que explican intuiciones operativas y recursos que describen relaciones de infraestructura. El flujo de un usuario hacia Cloudflare, la comparación entre Firebase solo vs Firebase + Cloudflare, la configuración DNS, el panel principal de Cloudflare y los beneficios de utilizar una CDN se comprenden mejor como imágenes didácticas, porque ayudan a construir una visión clara del recorrido principal y de la utilidad práctica del servicio. En cambio, la arquitectura completa Cloudflare → Firebase Hosting, el flujo DNS → Cloudflare → Firebase, la arquitectura de seguridad, el flujo de caché y la integración con Authentication, Firestore y Cloud Functions deben representarse como diagramas SVG, porque muestran capas de red, decisiones de proxy, tránsito entre servicios y componentes de seguridad que requieren precisión estructural.[cite:1][cite:2]

Imágenes didácticas

  1. Flujo de un usuario hacia Cloudflare. Conviene como imagen didáctica porque introduce visualmente la idea de capa frontal.
  2. Comparación Firebase solo vs Firebase + Cloudflare. Es mejor como imagen didáctica porque permite contrastar beneficios y costos operativos de forma accesible.
  3. Configuración DNS. Debe ser imagen didáctica porque el objetivo principal es reconocer registros y su propósito.
  4. Panel principal de Cloudflare. Conviene como imagen didáctica porque familiariza al lector con la interfaz operativa.
  5. Beneficios de utilizar una CDN. Debe ser imagen didáctica porque refuerza el concepto con ejemplos simples de cercanía y distribución.

Diagramas SVG

  1. Arquitectura completa Cloudflare → Firebase Hosting. Debe resolverse como SVG porque requiere mostrar la capa de proxy, la resolución DNS, el origen y la entrega desde edge.[cite:1][cite:2]
  2. Flujo DNS → Cloudflare → Firebase. Conviene SVG porque representa con precisión el cambio de resolución hacia IPs anycast de Cloudflare y el reenvío al origen.[cite:1]
  3. Arquitectura de seguridad. Debe ser SVG porque combina WAF, DDoS protection, reglas, rate limiting y origen protegido.
  4. Flujo de caché. Debe ser SVG porque necesita representar hits, misses, paso por proxy y respuesta desde edge.
  5. Integración con Authentication, Firestore y Cloud Functions. Debe ser SVG porque muestra qué tráfico pasa por Hosting/Cloudflare y qué tráfico va directamente a otros servicios Firebase.

Objetivos de aprendizaje

Al finalizar este capítulo, el lector será capaz de:

  • Comprender por qué una arquitectura Cloudflare + Firebase Hosting puede aportar valor en producción y cuándo no es necesaria.
  • Explicar el papel de Cloudflare como capa frontal de DNS, proxy, rendimiento y seguridad.[cite:1][cite:2]
  • Configurar conceptualmente un dominio en Cloudflare y dirigirlo a Firebase Hosting con una estrategia adecuada de DNS y SSL.[cite:1][cite:2]
  • Entender cómo influyen el proxy, el caché, HTTP/2, HTTP/3 y Brotli en el rendimiento percibido de una aplicación moderna.[cite:1][cite:2]
  • Relacionar WAF, DDoS protection, rate limiting y protección de bots con la publicación de aplicaciones reales en Internet.[cite:3][cite:4]
  • Diseñar una arquitectura de producción para el proyecto oficial del libro usando Firebase Hosting como origen de frontend y Cloudflare como capa externa empresarial.

Introducción

Firebase Hosting ya ofrece una base muy sólida para publicar aplicaciones web: CDN global, HTTPS, compresión y despliegues simples. Entonces surge una pregunta razonable: si Hosting ya es rápido y seguro, ¿por qué agregar Cloudflare delante?

La respuesta correcta no es “siempre hay que hacerlo”. En realidad depende del contexto. Cloudflare puede aportar valor cuando se necesita una capa adicional y más controlable de DNS, proxy, seguridad, observabilidad, reglas de tráfico y optimización avanzada. Su fortaleza no está solo en acelerar contenido, sino en convertirse en una plataforma frontal de red para la aplicación.[cite:1][cite:2]

La documentación de Cloudflare explica que, cuando un registro DNS está en modo Proxied, el tráfico HTTP/HTTPS deja de ir directamente al origen y pasa primero por la red de Cloudflare. En ese punto Cloudflare puede optimizar, cachear, proteger y aplicar reglas a las solicitudes antes de reenviarlas al origen.[cite:1] Si el origen de frontend es Firebase Hosting, la arquitectura resultante se convierte en una doble capa: Cloudflare al frente como plano de entrada y Firebase Hosting como plano de publicación del contenido web.

Esto abre posibilidades muy interesantes en producción. Cloudflare puede ocultar el origen detrás de direcciones anycast, aplicar WAF, absorber ataques DDoS, imponer rate limiting, mejorar el control DNS, reforzar la analítica y habilitar políticas de tráfico más sofisticadas.[cite:1][cite:3][cite:4] A la vez, Firebase Hosting mantiene su ventaja como plataforma de despliegue simple y bien integrada con el ecosistema Firebase.

El objetivo de este capítulo es enseñar cómo pensar y diseñar esa combinación. No se trata solo de “poner una nube naranja” en Cloudflare, sino de entender qué sucede internamente, qué beneficios reales se obtienen, qué riesgos aparecen, qué configuraciones son compatibles con Firebase Hosting y en qué escenarios una capa adicional resulta innecesaria o incluso contraproducente.

Desarrollo completo

Introducción arquitectónica

¿Por qué utilizar Cloudflare junto con Firebase Hosting?

Porque resuelven capas diferentes del problema. Firebase Hosting resuelve muy bien la publicación del frontend y su integración con el ecosistema Firebase. Cloudflare resuelve muy bien el control de entrada del tráfico web, la administración profesional del DNS y un conjunto amplio de optimizaciones y defensas perimetrales.

La documentación de Cloudflare sobre proxy status lo resume con claridad: cuando un registro está Proxied, Cloudflare se sitúa entre los visitantes y el servidor de origen, optimizando, cacheando y protegiendo el tráfico.[cite:1] Esa función es exactamente la que resulta atractiva en entornos empresariales donde no basta con “servir la app”, sino que también importa tener una capa avanzada de red y seguridad delante del origen.

Arquitectura general

La arquitectura general puede describirse así:

  1. El usuario consulta el dominio.
  2. El DNS del dominio está administrado por Cloudflare.
  3. Si el registro está en modo proxied, la resolución devuelve IPs anycast de Cloudflare en lugar de la dirección real del origen.[cite:1]
  4. El navegador establece la conexión con Cloudflare.
  5. Cloudflare aplica su lógica de seguridad, caché, optimización y enrutamiento.
  6. Cloudflare reenvía la solicitud al origen configurado, que en este caso es Firebase Hosting.
  7. Firebase Hosting entrega el recurso o responde según su propia configuración.
  8. Cloudflare devuelve la respuesta al usuario y, si corresponde, la almacena o reutiliza desde su red edge.

Desde fuera, el usuario percibe un único sitio. Internamente, existen dos capas especializadas.

Ventajas de integrar ambos servicios

Las ventajas más relevantes suelen ser:

  • DNS administrado de forma centralizada por Cloudflare.
  • Capa adicional de caché y optimización.
  • Protección DDoS y WAF delante del origen.[cite:3][cite:4]
  • Posibilidad de reglas de firewall, bot control y rate limiting.
  • Mayor control operativo sobre tráfico, certificados y políticas del borde.
  • Mejor preparación para arquitecturas empresariales con múltiples subdominios o servicios.

Casos donde no es necesario utilizar Cloudflare

No siempre conviene. Si la aplicación es pequeña, tiene tráfico moderado, no requiere políticas de seguridad avanzadas y ya funciona bien con Firebase Hosting y un dominio personalizado, añadir Cloudflare puede incrementar complejidad sin generar un beneficio proporcional.

También puede ser innecesario cuando el equipo no tiene madurez operativa suficiente para administrar otra capa de infraestructura. Una arquitectura más poderosa pero mal entendida puede terminar produciendo más problemas que ventajas.

Cloudflare como capa frontal

DNS administrado

Cloudflare no es solo un proxy; también es un proveedor de DNS administrado. Cuando se migra un dominio a Cloudflare, normalmente se actualizan los nameservers del registrador para que la zona DNS sea servida por Cloudflare. A partir de ese momento, todos los registros se gestionan desde su panel.

Esta centralización es valiosa porque permite administrar subdominios, proxied status, certificados, reglas y otras capacidades desde una sola interfaz.

Proxy inverso

La esencia del modelo está en el proxy. La documentación oficial indica que, cuando un registro A, AAAA o CNAME está proxied, las consultas DNS resuelven a IPs anycast de Cloudflare y todo el tráfico HTTP/HTTPS pasa primero por su red.[cite:1]

Un proxy inverso actúa como intermediario frontal. El cliente no habla directamente con el origen, sino con Cloudflare, que luego decide cómo y cuándo consultar al origen real. Esta mediación es la base tanto del rendimiento adicional como de la seguridad perimetral.

CDN global

Cloudflare opera una red global distribuida y, cuando el tráfico pasa por ella, puede cachear y servir respuestas desde ubicaciones cercanas. Esta es una de las razones por las que resulta útil incluso delante de un origen que ya tiene CDN: permite definir otra capa de política, protección y distribución, a veces con objetivos distintos al servicio de origen.

Edge Network

El edge network es el conjunto de data centers y puntos de presencia desde los cuales Cloudflare recibe y procesa tráfico. En una arquitectura con Firebase Hosting, el edge de Cloudflare se convierte en la primera capa geográfica de recepción; Firebase Hosting queda como origen del frontend, protegido y mediado por esa red.

Caché inteligente

Una vez proxied, Cloudflare puede cachear contenido y aplicar sus propias reglas. Esto no reemplaza automáticamente la lógica de caché de Firebase Hosting, pero sí agrega una capa adicional de decisión. Bien configurada, puede reducir solicitudes repetidas al origen y mejorar tiempo de respuesta para ciertos recursos.

Balanceo de carga (introducción)

Cloudflare también ofrece load balancing, aunque en esta arquitectura básica suele considerarse un tema avanzado o complementario. La documentación de Cloudflare distingue entre balanceo Layer 7 proxied y DNS-only, y aclara que el modo proxied permite decisiones más ricas sobre el tráfico HTTP/HTTPS.[cite:5] En el caso de Firebase Hosting, normalmente no se empieza por ahí, pero es útil saber que existe como parte de un ecosistema mayor.

Always Online

Cloudflare dispone de características orientadas a resiliencia y continuidad. Aunque no sustituyen al origen ni a un diseño correcto de la aplicación, ayudan a reducir impacto frente a ciertas interrupciones temporales del backend o del sitio principal.

Smart Routing

Cloudflare también incluye capacidades de optimización de trayectos por su red. Conceptualmente, esto significa que no solo actúa como puerta de entrada, sino que intenta llevar la solicitud por rutas internas más convenientes para reducir latencia y mejorar estabilidad en ciertos escenarios.

Configuración

Agregar un dominio a Cloudflare

El primer paso consiste en añadir la zona del dominio a Cloudflare. Esto permite que Cloudflare analice registros existentes y prepare la administración centralizada del DNS. Una vez hecho esto, Cloudflare asigna nameservers propios para la zona.

Configuración de Nameservers

Luego debe actualizarse el registrador del dominio para usar los nameservers de Cloudflare. Este paso cambia el control autoritativo del DNS. A partir de aquí, cualquier resolución del dominio dependerá de la configuración que se haga en Cloudflare.

Esta fase debe ejecutarse con cuidado porque un error puede afectar no solo la web, sino también correo y otros subdominios si la zona no se replica correctamente.

Registros DNS

Ya dentro de Cloudflare, se configuran los registros que apuntarán a Firebase Hosting. Aquí es fundamental distinguir entre registros que sirven tráfico web y registros usados para verificación.

La documentación oficial explica que solo los registros A, AAAA y CNAME pueden ponerse en modo proxied. Otros como TXT siempre quedan DNS-only.[cite:1] Esta regla importa mucho porque los TXT de verificación y ciertos registros de control del dominio no deben pasar por el proxy.

Registros A

Un dominio raíz suele resolverse mediante registros A o AAAA. Cuando esos registros sirven tráfico web y se quiere que Cloudflare actúe como capa frontal, deben configurarse en modo proxied.[cite:1]

Registros CNAME

Los subdominios suelen apuntarse con CNAME. Cloudflare también puede proxyar CNAME y, cuando lo hace, resuelve la cadena y entrega IPs anycast propias al cliente.[cite:1]

Configuración para Firebase Hosting

Cuando el origen es Firebase Hosting, la configuración DNS debe respetar las necesidades de verificación del dominio en Firebase y, después, apuntar el tráfico web al destino apropiado. En una configuración profesional, la secuencia recomendada es:

  1. verificar primero el dominio y completar requisitos de Firebase;
  2. confirmar que el dominio responde correctamente en Hosting;
  3. migrar la gestión DNS a Cloudflare o administrar el subdominio correspondiente allí;
  4. activar el proxy únicamente en los registros web que deben pasar por Cloudflare;
  5. dejar en DNS-only los registros de verificación o servicios no web.

Certificados SSL

Cloudflare gestiona una conexión entre visitante y Cloudflare, y otra entre Cloudflare y el origen. La documentación oficial de SSL/TLS encryption modes describe explícitamente este doble tramo.[cite:2] Esto encaja muy bien con Firebase Hosting, ya que Hosting ya sirve contenido por HTTPS con certificados válidos.

Modos SSL

Cloudflare ofrece varios modos de cifrado: Off, Flexible, Full, Full (strict) y otras variantes más específicas.[cite:2] Para el lector, lo esencial es comprender que el modo elegido define cómo Cloudflare se conecta con el origen y si valida o no su certificado.

HTTPS estricto

La propia documentación recomienda usar Full o Full (strict) cuando sea posible para prevenir conexiones maliciosas al origen.[cite:2] En una integración con Firebase Hosting, la opción profesional suele ser Full (strict) porque Hosting ya ofrece certificados válidos. Esto mantiene cifrado extremo a extremo y exige validación del certificado del origen.

Es importante evitar Flexible en este escenario. Flexible cifra solo entre visitante y Cloudflare, pero no entre Cloudflare y el origen.[cite:2] Con un origen como Firebase Hosting, eso introduce una degradación innecesaria y puede generar comportamientos extraños o redirecciones no deseadas.

Rendimiento

Caché de contenido estático

Cuando un registro está proxied, Cloudflare puede optimizar, cachear y proteger solicitudes destinadas a la aplicación.[cite:1] En una app basada en Firebase Hosting, esto es más útil sobre activos verdaderamente estáticos como JS compilado, CSS, imágenes públicas o fuentes, siempre que la política de caché esté bien pensada.

Compresión automática

Tanto Firebase Hosting como Cloudflare aportan optimizaciones de entrega. El resultado práctico para el lector es que el contenido puede viajar comprimido y llegar más rápido al navegador. Pero la doble capa obliga a entender bien headers y caché para evitar supuestos incorrectos.

Brotli

Cloudflare y Firebase Hosting soportan tecnologías modernas de compresión. Firebase Hosting ya sirve contenido usando gzip o Brotli según convenga.[cite:6] Cloudflare también opera con optimizaciones de protocolo y compresión en su borde. Para el desarrollador, lo importante es comprender que el rendimiento no viene solo de la proximidad geográfica, sino también de transferir menos bytes.

HTTP/2

Cloudflare documenta que para registros proxied, si el dominio tiene habilitado HTTP/2 y HTTP/3 junto con Universal SSL, puede generar registros HTTPS dinámicos para ayudar a los clientes a conectarse usando protocolos modernos desde el principio.[cite:1] Esto refuerza la idea de que la capa frontal también influye en cómo se negocia la conexión.

HTTP/3

HTTP/3 aporta mejoras en latencia y recuperación frente a ciertos problemas de red, especialmente al apoyarse en QUIC. Cloudflare lo integra dentro de su optimización de protocolo del borde.[cite:1]

QUIC

QUIC, como base de HTTP/3, forma parte de esta evolución del transporte web. En el contexto de este capítulo, basta con comprender que la capa Cloudflare puede mejorar la experiencia de red del usuario sin que el equipo tenga que operar manualmente una infraestructura propia de edge protocol negotiation.

Optimización de imágenes

Cloudflare ofrece capacidades específicas de optimización de imágenes como Polish y Mirage, orientadas a reducir peso y mejorar entrega en distintos dispositivos. Estas funciones son especialmente atractivas cuando el frontend depende de abundantes imágenes públicas, catálogos, banners o recursos editoriales.

Minificación automática

Cloudflare también puede realizar ciertas optimizaciones automáticas de contenido textual como CSS, JS o HTML, según el plan y la configuración. Sin embargo, esto no debe reemplazar un build correcto. La regla profesional sigue siendo generar un artefacto de producción optimizado antes de llegar al edge.

Polish

Polish está orientado a optimización de imágenes. En aplicaciones con carga visual intensa puede reducir consumo de ancho de banda y mejorar tiempos de carga. El lector debe entenderlo como una optimización del borde, no como sustituto de una estrategia integral de assets.

Mirage

Mirage complementa la entrega de imágenes, especialmente en conexiones o dispositivos limitados. En arquitecturas con frontend público y contenido gráfico abundante puede mejorar experiencia percibida en redes lentas.

Seguridad

Firewall

Una de las grandes razones para usar Cloudflare delante de Firebase Hosting es su papel como firewall perimetral. Cloudflare puede aplicar reglas antes de que la solicitud llegue al origen, lo que ofrece una superficie de defensa adicional para sitios públicos.

Protección DDoS

La documentación oficial de Cloudflare indica que detecta y mitiga automáticamente ataques DDoS en todos sus planes.[cite:3] Además, la guía sobre proxying DNS records explica que, cuando los registros están proxied, las solicitudes se resuelven hacia IPs anycast de Cloudflare y el origen queda más protegido frente a ataques dirigidos.[cite:4]

Esto no significa invulnerabilidad, pero sí una mejora significativa del perímetro de protección respecto a exponer directamente el origen.

WAF

Cloudflare proporciona un WAF configurable para proteger frente a vulnerabilidades comunes y aplicar reglas gestionadas o personalizadas. La combinación de WAF y proxy frontal resulta especialmente valiosa en rutas sensibles como login, panel administrativo o APIs expuestas vía rewrites hacia Functions.

Rate Limiting

El rate limiting ayuda a limitar abusos, fuerza bruta y comportamientos anómalos sobre rutas concretas. En una plataforma educativa puede aplicarse, por ejemplo, a endpoints de autenticación, formularios públicos o recursos donde el abuso pueda degradar servicio o costos.

Bot Protection

Cloudflare también dispone de mecanismos para identificar y mitigar tráfico automatizado. Esto es útil no solo para scraping o abuso, sino para proteger formularios, pantallas de acceso y endpoints susceptibles a automatización maliciosa.

Reglas de seguridad

Una ventaja de operar Cloudflare al frente es que muchas políticas pueden definirse sin tocar directamente el código del frontend ni modificar el origen. Reglas por URL, país, patrón de tráfico o reputación pueden convertirse en parte de la defensa operacional.

Protección de APIs

Si el frontend servido por Hosting consume APIs vía Functions o Cloud Run y esas rutas pasan por dominios protegidos por Cloudflare, es posible aplicar parte de esta capa de seguridad también sobre el tráfico API. Esto puede complementar, pero nunca reemplazar, autenticación, autorización y validaciones backend.

Integración con Firebase

Authentication

Cloudflare no reemplaza Firebase Authentication. La autenticación sigue ocurriendo mediante los mecanismos de Firebase o del frontend. Pero la capa Cloudflare puede proteger mejor las rutas de acceso, mitigar abuso automatizado y filtrar parte del tráfico sospechoso antes de que llegue a la interfaz pública.

Firestore

El tráfico directo del SDK desde el navegador hacia Firestore no pasa necesariamente por Firebase Hosting ni por Cloudflare, salvo arquitecturas muy específicas. Por eso es importante comprender el límite de la integración: Cloudflare protege el dominio del frontend y las rutas que efectivamente pasan por él, no todo el tráfico de datos del ecosistema Firebase por defecto.

Cloud Storage

Lo mismo aplica a parte del acceso a Storage. Si ciertos binarios se descargan por rutas propias o mediante frontend alojado, Cloudflare puede influir en la experiencia del sitio. Pero no debe asumirse que toda operación de Storage queda automáticamente cubierta por la misma capa frontal.

Cloud Functions

Aquí la integración puede ser más interesante. Si el frontend hace rewrites o consume endpoints detrás del mismo dominio, Cloudflare puede añadir seguridad y políticas sobre ese tráfico. Sin embargo, el equipo debe cuidar headers, caché y reglas para no romper endpoints dinámicos o sensibles.

Hosting

Firebase Hosting sigue siendo el origen frontend. Cloudflare no sustituye a Hosting; lo envuelve y lo potencia en ciertos escenarios. La clave es entender cuál capa hace qué:

  • Firebase Hosting: publica y sirve el frontend como origen integrado con Firebase.[cite:6]
  • Cloudflare: administra DNS, recibe tráfico, lo protege, lo optimiza y lo reenvía al origen cuando corresponde.[cite:1][cite:2]

Reglas de compatibilidad

La integración funciona mejor cuando el equipo respeta algunas reglas:

  • dejar DNS-only los registros de verificación;
  • usar proxied solo en tráfico web real compatible con Cloudflare proxy.[cite:1]
  • configurar SSL en Full (strict) cuando el origen tenga certificado válido.[cite:2]
  • evitar políticas de caché agresivas sobre rutas dinámicas o sensibles;
  • probar cuidadosamente login, callbacks y rewrites.

Casos reales

Plataforma educativa

En el proyecto oficial del libro, mover la plataforma educativa a Cloudflare delante de Firebase Hosting aporta varias mejoras prácticas:

  • dominio corporativo administrado profesionalmente;
  • DNS centralizado;
  • protección adicional para el frontend y el panel administrativo;
  • posibilidad de reglas por rutas sensibles como login o expedientes;
  • mejor control operacional sobre caché y tráfico.

Esta arquitectura es superior a Firebase Hosting solo cuando el sistema ya exige controles perimetrales más ricos. Para una plataforma con crecimiento institucional, paneles administrativos y documentación sensible, suele ser una evolución razonable.

SaaS

En un SaaS con múltiples subdominios, paneles y clientes empresariales, Cloudflare puede unificar el plano DNS y añadir una capa de seguridad y observabilidad difícil de reproducir solo con Hosting.

Portal institucional

Un portal institucional con tráfico irregular, campañas de comunicación y riesgo de picos también puede beneficiarse del edge y de la protección DDoS adicional de Cloudflare.[cite:3]

Sistema administrativo

Un sistema administrativo expuesto a Internet se beneficia especialmente de WAF, rate limiting y reglas específicas sobre rutas de autenticación y gestión interna.

Aplicaciones de alto tráfico

En escenarios de alto tráfico, la combinación de caché edge, anycast, mitigación DDoS y control fino del tráfico puede aportar resiliencia operacional más allá de la publicación básica del frontend.

Comparaciones técnicas

Firebase Hosting solo vs Firebase Hosting + Cloudflare

Aspecto Firebase Hosting solo Firebase Hosting + Cloudflare
DNS Suficiente para conectar dominio, menos centralizado DNS administrado desde Cloudflare con control unificado
Capa frontal Hosting recibe tráfico directamente Cloudflare recibe primero el tráfico y actúa como proxy [cite:1]
SSL hacia el usuario Sí, con certificados de Firebase [cite:6] Sí, y además Cloudflare controla el tramo visitante→Cloudflare [cite:2]
SSL hacia el origen Gestionado por Hosting [cite:6] Debe configurarse correctamente, idealmente Full (strict) [cite:2]
Protección DDoS Base de Google/Firebase Capa perimetral explícita de Cloudflare [cite:3][cite:4]
WAF y reglas avanzadas Más limitado desde la capa Hosting Amplio conjunto de reglas y productos de seguridad
Complejidad Menor Mayor, pero con más control

Proxied vs DNS-only en Cloudflare

Modo Qué ocurre Cuándo usar
Proxied Cloudflare responde con IPs anycast y el tráfico web pasa por su red [cite:1] Sitios y subdominios web que deben optimizarse y protegerse
DNS-only Se expone la dirección real del origen y Cloudflare no procesa HTTP/HTTPS [cite:1] Registros no web, verificaciones, correo o casos incompatibles

SSL Flexible vs Full (strict)

Modo Tramo visitante→Cloudflare Tramo Cloudflare→origen Recomendación
Flexible Cifrado posible Sin cifrado [cite:2] Evitar con Firebase Hosting
Full Cifrado HTTPS sin validar certificado [cite:2] Mejor que Flexible, pero no ideal
Full (strict) Cifrado HTTPS con validación de certificado [cite:2] Opción profesional recomendada

Buenas prácticas

  • Migrar primero el dominio y verificar que Hosting funciona correctamente antes de activar optimizaciones agresivas.
  • Mantener en DNS-only los registros de verificación y otros servicios no web.[cite:1]
  • Usar proxy solo en A, AAAA y CNAME que sirvan HTTP/HTTPS.[cite:1]
  • Configurar SSL/TLS en Full (strict) siempre que el origen tenga certificado válido, como ocurre con Firebase Hosting.[cite:2]
  • Empezar con reglas de caché conservadoras y medir antes de endurecerlas.
  • Aplicar WAF y rate limiting primero en rutas sensibles.
  • Documentar claramente qué tráfico pasa por Cloudflare y cuál no.
  • No asumir que Cloudflare protege automáticamente todas las llamadas directas del frontend a servicios Firebase.
  • Revisar periódicamente logs, eventos de seguridad y cambios DNS.
  • Tratar el DNS como infraestructura crítica, no como configuración secundaria.

Errores comunes

  • Activar proxy en registros que deberían permanecer DNS-only, como ciertos TXT de verificación.[cite:1]
  • Elegir Flexible SSL aunque el origen ya soporte HTTPS correctamente.[cite:2]
  • Aplicar caché agresiva sobre contenido dinámico o endpoints sensibles.
  • Asumir que toda la arquitectura Firebase queda automáticamente detrás de Cloudflare.
  • Añadir Cloudflare solo “porque suena más profesional” sin una necesidad real.
  • No probar login, callbacks y panel administrativo después de cambiar DNS o proxy.
  • Confundir mejora de seguridad perimetral con seguridad completa de aplicación.
  • No documentar el proceso de rollback DNS o de desactivación del proxy si algo sale mal.

Resumen

Integrar Cloudflare con Firebase Hosting tiene sentido cuando la aplicación necesita una capa frontal más rica que combine DNS administrado, proxy inverso, optimización de red y defensa perimetral. La clave técnica está en que los registros web se configuren como Proxied, lo que hace que las consultas DNS respondan con IPs anycast de Cloudflare y que el tráfico HTTP/HTTPS pase primero por su red antes de llegar al origen.[cite:1]

Esa arquitectura añade capacidades valiosas. Cloudflare puede optimizar, cachear y proteger el tráfico, aplicar WAF y reglas adicionales, y mitigar automáticamente ataques DDoS. Al mismo tiempo, Firebase Hosting sigue actuando como origen moderno de frontend, con despliegues simples, CDN propia, HTTPS y fuerte integración con el ecosistema Firebase.[cite:3][cite:4][cite:6]

La configuración SSL es una de las decisiones más importantes de la integración. Cloudflare administra dos conexiones distintas, visitante→Cloudflare y Cloudflare→origen, y su documentación recomienda usar Full o Full (strict) cuando sea posible. En una integración con Firebase Hosting, Full (strict) suele ser la opción profesional adecuada porque el origen ya dispone de certificados válidos.[cite:2]

No obstante, esta arquitectura no siempre es necesaria. Para proyectos pequeños o con requisitos sencillos, Firebase Hosting por sí solo suele ser suficiente. Cloudflare aporta valor real cuando el dominio, la seguridad perimetral, el control del tráfico y la operación empresarial justifican una capa adicional. En el proyecto transversal del libro, esta integración representa el paso hacia una infraestructura web moderna, mejor gobernada y más preparada para producción institucional o de alto tráfico.

Conceptos clave

  • Cloudflare como capa frontal.
  • Proxy inverso.[cite:1]
  • DNS administrado.
  • Proxy status.[cite:1]
  • Proxied vs DNS-only.[cite:1]
  • Anycast IPs.[cite:1]
  • Edge network.
  • Capa perimetral.
  • SSL/TLS modes.[cite:2]
  • Full (strict).[cite:2]
  • DDoS protection.[cite:3][cite:4]
  • WAF.
  • Rate limiting.
  • Bot protection.
  • Caché edge.
  • HTTP/2.[cite:1]
  • HTTP/3.[cite:1]
  • QUIC.
  • Firebase Hosting como origen.[cite:6]

Preguntas de repaso

  1. ¿Por qué podría tener sentido colocar Cloudflare delante de Firebase Hosting en una arquitectura de producción?
  2. ¿Qué hace Cloudflare cuando un registro DNS está en modo Proxied?[cite:1]
  3. ¿Qué diferencia existe entre un registro proxied y uno DNS-only?[cite:1]
  4. ¿Por qué no todos los registros DNS deben pasar por el proxy de Cloudflare?[cite:1]
  5. ¿Qué función cumple el modo SSL/TLS dentro de la integración Cloudflare → origen?[cite:2]
  6. ¿Por qué Full (strict) suele ser la mejor opción cuando el origen es Firebase Hosting?[cite:2]
  7. ¿Qué aporta Cloudflare en materia de DDoS y WAF frente a una publicación sin esta capa adicional?[cite:3][cite:4]
  8. ¿Qué límites tiene la integración con respecto a tráfico directo del frontend hacia Firestore o Storage?
  9. ¿En qué casos agregar Cloudflare puede ser innecesario o contraproducente?
  10. ¿Cómo aplicarías esta arquitectura al proyecto educativo del libro para mejorar rendimiento y seguridad?

Ejercicios prácticos

  1. Dibuja la arquitectura completa del proyecto del libro con Cloudflare como capa frontal y Firebase Hosting como origen del frontend.
  2. Diseña una propuesta de subdominios para app, admin, staging y docs, indicando cuáles deberían pasar por proxy.
  3. Escribe un procedimiento paso a paso para migrar el dominio del proyecto a Cloudflare sin perder la conectividad con Firebase Hosting.
  4. Explica qué registros mantendrías en DNS-only y por qué.[cite:1]
  5. Diseña una política básica de seguridad en Cloudflare para proteger login y panel administrativo.
  6. Analiza qué contenido del proyecto educativo podría beneficiarse de caché edge adicional y qué contenido no debería cachearse agresivamente.
  7. Compara la arquitectura Firebase solo vs Firebase + Cloudflare desde perspectiva de costo, seguridad y complejidad.
  8. Propón una estrategia de validación posterior al cambio de nameservers y activación del proxy.
  9. Explica cómo responderías si después de activar Cloudflare una ruta crítica empieza a fallar por redirecciones o TLS.
  10. Redacta un checklist de producción para operar esta arquitectura de forma segura.

Bibliografía y referencias oficiales