Chrome 154 Pide Antes de Cargar HTTP: ¿Qué Cambia para Desarrollo, Staging y Automatización de Pruebas?

Si alguna vez has compartido un enlace de staging que empieza con http://, Chrome ahora tiene una opinión al respecto. Chrome 154 activó “Always Use Secure Connections” de forma predeterminada. Chrome intenta primero HTTPS y solicita el permiso del usuario antes de la primera visita a un sitio público que no pueda alcanzarse mediante HTTPS.

Para el visitante medio de un sitio moderno, no cambia nada. Para los desarrolladores, la historia es distinta. El dolor no recae en localhost, que está exento. Recae en las esquinas más discretas de un flujo de trabajo real: servidores de staging con nombres de host públicos, entornos de vista previa a los que nadie les puso un certificado, cadenas de redirección antiguas y trabajos de CI donde no hay nadie para hacer clic en “Continuar.”

Esta guía cubre lo que se implementó, cómo se comporta la advertencia, dónde rompe los flujos de desarrollo y QA, la bandera exacta para la automatización de pruebas y cómo solucionar el problema subyacente en lugar de parchearlo.

Resumen

• Chrome 154 llegó al canal estable el 22 de septiembre de 2026, con la variante para sitios públicos de “Always Use Secure Connections” activada por defecto. La publicación de lanzamiento de Google siguió el 21 de octubre de 2026.
• Chrome intenta primero HTTPS. Si eso falla pero HTTP podría funcionar, pregunta antes de cargar la página mediante HTTP.
• localhost, direcciones IP locales, nombres de host de una sola etiqueta y nombres no únicos como staging.local no activan la advertencia.
• Un nombre de host público servido a través de HTTP simple puede activarlo. Para una persona, hacer clic para continuar sigue funcionando, así que es fricción en lugar de un muro. Para automatización desatendida, puede ser un obstáculo.
• Para la automatización de pruebas, la ruta de escape documentada de Chromium es --unsafely-treat-insecure-origin-as-secure.
• La solución durable es HTTPS en cada nombre de host público, incluyendo cada salto de cada redirección.

Lo que realmente cambió Chrome 154

La configuración “Always Use Secure Connections” no es nueva. Chrome la introdujo en 2022 como una función opt-in. Google añadió más tarde una variante limitada a sitios públicos, porque HTTP hacia sitios privados conlleva menos riesgo. Lo que cambió en Chrome 154 es que se convirtió en predeterminada.

Aquí está la implementación, según lo describió Google:

Cuando	Qué sucedió
2022	“Always Use Secure Connections” se lanza como configuración opt-in
2024	Se introduce una variante solo para sitios públicos
Chrome 141	Google experimenta con habilitar la variante para sitios públicos para un pequeño porcentaje de usuarios
28 de octubre de 2025	El equipo de Seguridad de Chrome anuncia el plan para que sea el predeterminado
Chrome 147 (abril de 2026)	Habilitado por defecto para usuarios inscritos en Enhanced Safe Browsing, un grupo anunciado por Google que supera mil millones de personas
Chrome 154 (22 de septiembre de 2026)	Habilitado por defecto para todos, según las notas de la versión de Chrome 154
21 de octubre de 2026	Google publica “Chrome Now Warns Before Insecure HTTP Connections,” confirmando la implementación para todos los usuarios

Un detalle que vale la pena corregir si leíste la cobertura inicial. El anuncio original decía que el cambio llegaría en octubre de 2026. Chrome 154 realmente alcanzó la fase estable el 22 de septiembre de 2026, porque Chrome pasó a un ciclo de lanzamiento de dos semanas a partir de Chrome 153, el 8 de septiembre. Las notas de la versión de Chrome 154 enumeran “Pedir antes de HTTP por defecto” y dicen que los administradores pueden controlarlo con la política empresarial HttpsOnlyMode. Como sucede con cualquier versión estable, la implementación en todas las máquinas ocurre gradualmente, por lo que aún puedes encontrar algunas versiones antiguas en uso.

¿Por qué hizo Google esto? Según el equipo de seguridad de Chrome, la proporción de cargas de páginas de Chrome que usan HTTPS aumentó de aproximadamente 30 a 45 por ciento en 2015 hasta el rango del 95 al 99 por ciento alrededor de 2020, y desde entonces ha permanecido relativamente estable. El trozo restante importa por dos razones:

• Un atacante necesita solo una navegación insegura para obtener una base, por ejemplo secuestrando la navegación y cargando recursos controlados por el atacante.
• Muchas conexiones HTTP en texto plano son invisibles para los usuarios, porque el sitio HTTP redirige inmediatamente a HTTPS. La antigua etiqueta “Not Secure” nunca tiene la oportunidad de aparecer.

En el experimento de Chrome 141, las advertencias alcanzaron mucho menos del 3 por ciento de las navegaciones. El usuario medio vio menos de una advertencia por semana, y el usuario del percentil 95 vio menos de tres. La publicación de Google de octubre de 2026 añade datos de implementación temprana: casi el 95 por ciento de los usuarios de Chrome en escritorio no ven advertencias HTTP en una semana dada, y menos del 1 por ciento ve tres o más. Las tasas de advertencia en móviles son aún más bajas. Google también señala que Chrome es el primer navegador en hacer este cambio por defecto.

Cómo se comporta la advertencia

Entender la mecánica te ahorra perseguir fantasmas. Esto es lo que dice la guía de adopción de Chromium.

Disparador. La advertencia aparece cuando Chrome no puede conectarse mediante HTTPS, pero cree que podría conectarse mediante HTTP. Chrome entonces solicita antes de cargar la página.

Memoria. Chrome recuerda la decisión del usuario durante 15 días, y la excepción se renueva cada vez que el usuario vuelve a visitar el sitio. Si usas un sitio HTTP con regularidad, es posible que veas la advertencia solo una vez. La publicación de lanzamiento de Google la describe como que no habrá una nueva advertencia hasta que el sitio no se visite durante al menos dos semanas.

HTTPS explícito nunca retrocede. Si un enlace o la barra de direcciones especifica https:// y la conexión falla, obtienes una página de error de red normal y Chrome no intenta HTTP.

HSTS tiene prioridad. Si un sitio tiene HTTP Strict Transport Security configurado, Chrome no recurre a HTTP. HSTS tiene prioridad sobre actualizaciones automáticas y la nueva advertencia.

Los redireccionamientos cuentan. Si cualquier paso en una cadena de redirección no admite HTTPS, Chrome muestra la advertencia, incluso si el destino final es una página HTTPS válida. El ejemplo de la guía: https://www.example.com está bien, pero http://example.com redirige a http://www.example.com y el dominio raíz no tiene HTTPS. Los visitantes que escriben example.com reciben la advertencia. Varios saltos inseguros pueden significar varias advertencias en una sola navegación.

Los errores de certificado no cambian. Un certificado caducado o un servidor mal configurado sigue produciendo las advertencias de certificado existentes, y no se añade ningún tipo de advertencia adicional.

Las opciones existentes se respetan. Si ya habías configurado la opción de alguna manera, Chrome mantiene esa elección.

Qué está exento, y por qué les importa a los desarrolladores

Chrome divide el mundo en sitios públicos y privados, y la advertencia se aplica solo a sitios públicos. Los sitios privados quedan excluidos por dos motivos:

• Ejemplos son direcciones IP locales como 192.168.0.1, nombres de host de una sola etiqueta como intranet/, y enlaces cortos internos.
• No hay una forma práctica para que una autoridad de certificado valide y emita un certificado de confianza pública para un nombre no único, y los atacantes generalmente deben estar en la misma red para explotarlos.

Para el desarrollo local, la guía de adopción lo explica claramente:

• http://localhost se considera seguro y no muestra advertencia.
• Los nombres locales como staging.local, nombres de host no únicos, direcciones IP locales y nombres de host de una sola etiqueta tampoco muestran advertencia.
• Un servidor de desarrollo en un hostname público sin HTTPS puede mostrar la advertencia. Al hacer clic para continuar, el desarrollo continúa como hoy.

Esa última viñeta es la que importa. Tu portátil está bien. Tu caja de staging compartida en http://staging.yourcompany.com no lo está.

Las empresas pueden optar por la dirección contraria. La política HttpsOnlyMode puede configurarse como force_balanced_enabled para fijar el nuevo valor por defecto, o force_enabled para que los usuarios entren en modo estricto, donde las advertencias también aparecen para sitios privados.

Dónde encaja un túnel

Existe una situación que los pasos anteriores no resuelven con facilidad. Tienes un servidor de desarrollo ejecutándose en tu máquina, y un compañero de equipo, un cliente o un emisor de webhook necesita acceder desde fuera. Autoalojar HTTPS para un entorno desechable es más ceremonial de lo necesario.

Es aquí donde un túnel HTTPS demuestra su utilidad. InstaTunnel sirve túneles sobre HTTPS por defecto, por lo que la URL que compartes es una dirección https:// desde el primer clic. Un revisor que la abra no se encontrará con una advertencia de HTTP, y no tienes que proveer un certificado para un nombre de host que eliminarás mañana. Un subdominio personalizado estable también significa que el enlace que colocas en un ticket sigue funcionando, en lugar de volver a compartir una nueva URL en cada sesión.

Dos advertencias honestas se aplican a cualquier túnel, no solo al nuestro:

• Tu aplicación todavía se comunica mediante HTTP localmente. El túnel termina en HTTPS en el borde y reenvía a tu servidor de desarrollo. Si tu framework genera URL absolutas o fuerza redirecciones según el esquema de la solicitud, asegúrate de que confía correctamente en el encabezado del protocolo reenviado, o podrías ver bucles de redirección o problemas de contenido mixto. Muchos servidores de desarrollo también rechazan encabezados Host desconocidos por defecto, por lo que es posible que debas añadir el hostname del túnel a una configuración de allowed-hosts.
• Un túnel no es un sustituto de un entorno de staging real. Si un entorno compartido va a durar meses, dale un nombre de host real y un certificado automático. Usa el túnel para los casos de corta duración en los que necesitas compartirlo de inmediato.

Una nota de alcance: esto es un mecanismo distinto de los avisos de Acceso a Red Local de Chrome, que se refieren a una página pública que accede a tu red local. Chrome 154 también amplía esa área. Añade una opción targetAddressSpace al constructor de WebSocket, que permite que una conexión a un hostname público se trate como si fuera a un destino local o de bucle. Las notas de lanzamiento de Chrome 154 las describen como una forma de evitar las restricciones de contenido mixto al comunicarse con servidores locales sin HTTPS, siempre que el usuario otorgue permiso de red local. Ask-before-HTTP, por el contrario, trata de navegar a una página pública que carece de HTTPS.

Preguntas frecuentes

¿Chrome 154 bloquea sitios HTTP?
No. Pide permiso antes de la primera visita a un sitio HTTP público y la advertencia se puede evitar. Chrome también recuerda la opción durante 15 días y la renueva en cada visita.

¿http://localhost muestra la advertencia?
No. Chrome lo trata como seguro. Direcciones IP locales, nombres de host de una sola etiqueta y nombres no únicos como staging.local también están exentos.

¿Puedo desactivarlo para mí?
Sí. Desactiva “Always Use Secure Connections” en chrome://settings/security. Si lo configuras de cualquiera de las dos formas antes de Chrome 154, Chrome mantiene tu elección.

¿Cómo detengo la advertencia en Selenium o Playwright?
Pasa --unsafely-treat-insecure-origin-as-secure con los orígenes específicos o hosts comodín que utilicen tus pruebas.

¿Qué pasa con Firefox, Safari y Edge?
Según la guía de Chromium, los tres ya actualizan las navegaciones HTTP a HTTPS y ofrecen modos opcionales que advierten antes de retroceder a HTTP. La diferencia es que Chrome ahora habilita la advertencia por defecto.

La conclusión

Chrome 154 no rompió la web, y para la mayoría de sitios no cambió nada visible. Pero dejó una línea clara: público significa HTTPS. Los desarrolladores mantienen un pase libre en localhost y nombres privados, mientras que los servidores de staging, entornos de vista previa y la automatización de pruebas en hostnames públicos ahora requieren ya un certificado adecuado o una excepción deliberada y estrecha. Dedica una tarde a activar la configuración, recorrer tus entornos y corregir los hosts que muestran el aviso. Es más barato que explicar la advertencia a cada cliente que abre un enlace de demostración.

Fuentes

• HTTPS por defecto, Equipo de Seguridad de Chrome (28 oct 2025)
• Chrome Now Warns Before Insecure HTTP Connections, Chrome Secure Web and Networking Team (Oct 21, 2026)
• Adapting your website for Chrome’s “Ask-before-HTTP” warning, Chromium docs
• Chrome 154 release notes, Chrome for Developers
• Get features faster with Chrome’s two-week release cycle, Chrome for Developers Blog (Mar 3, 2026)
• Fresher features, faster fixes: The two-week release cycle is here, Chrome for Developers Blog (Sep 8, 2026)
• Google Chrome starts two-week release cycle with version 153, 9to5Google
• Chrome to Turn HTTPS on by Default for Public Sites, SecurityWeek
• Chrome Will Default to HTTPS for All Public Sites Starting October 2026, CyberInsider