HTTP vs HTTPS: por qué el navegador dice 'No es seguro'

Escribes la dirección de un sitio y el navegador muestra "No es seguro" a su lado. La mayoría de las veces la causa es sencilla: el sitio se abrió por http:// en lugar de https://. La diferencia es una letra en la dirección, pero cambia quién puede leer lo que viaja entre tú y el servidor.

Los navegadores son cada vez más insistentes con ese aviso, y un sitio solo en HTTP pierde visitantes. Migrar un sitio o una API a HTTPS sin romper enlaces, cookies ni imágenes lleva cuatro pasos, descritos más abajo.

¿Qué diferencia hay entre HTTP y HTTPS?#

HTTP es el protocolo que define cómo el navegador y el servidor intercambian peticiones y respuestas. No cifra nada: la URL, las cabeceras, las cookies y el cuerpo de la respuesta viajan en texto plano. HTTPS es el mismo HTTP, pero dentro de una conexión protegida por TLS. La aplicación sigue hablando HTTP; TLS se encarga de cifrar, detectar alteraciones y probar la identidad del servidor.

Los navegadores solo usan HTTP/2 y HTTP/3 sobre TLS. En la práctica, HTTPS suele ser tan rápido como HTTP, y muchas veces más.

¿Por qué el navegador muestra "No es seguro"?#

Porque en una conexión HTTP cualquier equipo en el camino ve y puede alterar la página: el Wi-Fi de la cafetería, el router del hotel, el proveedor de internet. Eso permite robar una cookie de sesión, cambiar un enlace de descarga o inyectar anuncios y scripts en tu página sin que lo sepas.

Google anunció, en octubre de 2025, que Chrome 154 activaría por defecto la opción "Always Use Secure Connections" para los sitios públicos. Con la opción activada, Chrome pide permiso al usuario antes de la primera visita a un sitio público sin HTTPS. El aviso no se repite en los sitios que la persona visita con frecuencia, y las direcciones privadas (IPs locales y nombres de host de intranet) quedan fuera. El usuario todavía puede desactivar la opción. En la práctica, un sitio solo en HTTP espanta a los visitantes nuevos antes incluso de cargar.

¿Qué protege HTTPS y qué no protege?#

Protege tres cosas en tránsito:

• Confidencialidad: quien intercepta ve bytes sin sentido, incluida la ruta de la URL y las cabeceras.
• Integridad: cualquier alteración en medio del camino se detecta.
• Autenticación: el certificado confirma que estás hablando con el servidor de ese dominio.

No protege lo que ocurre fuera de la conexión. HTTPS no corrige una inyección SQL, una contraseña débil ni un servidor comprometido, y el candado no prueba que el sitio sea honesto: un sitio de estafa también puede tener un certificado válido. El nombre del dominio y la IP de destino normalmente siguen siendo visibles para quien observa la red.

¿Cómo migrar un sitio de HTTP a HTTPS?#

La migración tiene cuatro pasos, en este orden.

1. Ten un certificado válido para el dominio. Autoridades como Let's Encrypt emiten certificados DV sin coste, y la renovación es automática en la mayoría de las plataformas.
2. Redirige todo el HTTP a HTTPS con una redirección permanente (301 o 308).
3. Activa HSTS después de confirmar que HTTPS funciona.
4. Corrige el contenido mixto, explicado más abajo.

Un ejemplo en Node.js con Express 5, detrás de un proxy que termina el TLS (el caso más común en hosting):

import express from "express";

const app = express();
const HOST = process.env.PUBLIC_HOST ?? "example.com"; // tu dominio canónico

// Confía en el primer proxy para leer X-Forwarded-Proto
app.set("trust proxy", 1);

app.use((req, res, next) => {
  if (!req.secure) {
    // Host fijo: nunca construyas la redirección a partir de una cabecera que controla el cliente
    return res.redirect(308, `https://${HOST}${req.originalUrl}`);
  }
  // 1 año; solo se envía en respuestas HTTPS
  res.set("Strict-Transport-Security", "max-age=31536000");
  next();
});

app.get("/", (req, res) => res.send("Hola por HTTPS"));

app.listen(process.env.PORT || 3000);

Sin trust proxy, la app ve la conexión local del proxy (HTTP puro) y req.secure siempre es falso, lo que genera un bucle de redirección. Entiende el motivo en proxy inverso. La redirección usa un dominio fijo porque, con trust proxy activado, req.hostname sale de la cabecera X-Forwarded-Host, y construir la URL a partir de ella podría mandar al visitante a otro sitio.

Comprueba el resultado con curl:

curl -sI http://example.com | head -n 3
curl -sI https://example.com | grep -i strict-transport-security

El primer comando debe mostrar una redirección a https://, y el segundo, la cabecera HSTS.

¿Qué es HSTS y cuándo activarlo?#

HSTS (HTTP Strict Transport Security) es una cabecera que le dice al navegador: "a este host solo se accede por HTTPS". Después de recibirla, el navegador convierte por su cuenta cualquier http:// en https:// durante el plazo max-age, en segundos, y el usuario no puede saltarse los errores de certificado. Así se cierra la brecha de la primera petición por HTTP, que la redirección sola deja abierta.

Strict-Transport-Security: max-age=31536000; includeSubDomains

El navegador ignora la cabecera en respuestas HTTP, así que solo vale cuando se envía por HTTPS. Para entrar en la lista de preload de los navegadores, el dominio necesita un max-age de al menos 31536000 (1 año), includeSubDomains y preload, y el envío se hace en hstspreload.org.

Cuidado: includeSubDomains obliga a que todos los subdominios tengan HTTPS funcionando. Empieza con un max-age corto (por ejemplo, 300) y súbelo poco a poco. Salir después de la lista de preload es lento, porque depende de nuevas versiones de los navegadores.

¿Qué es el contenido mixto y cómo se corrige?#

El contenido mixto ocurre cuando una página cargada por HTTPS pide recursos por http://. Es la causa más común de que un sitio con un certificado válido siga pareciendo roto.

Los navegadores tratan dos grupos de forma distinta. Las imágenes, el vídeo y el audio se actualizan automáticamente a HTTPS. Todo lo demás, como scripts, hojas de estilo, iframes, fetch() y fuentes, se bloquea. Si el host del recurso es una IP en lugar de un nombre de dominio, hasta la imagen se bloquea.

Para corregirlo:

• Cambia http:// por https:// en tus plantillas, o usa URLs relativas para los recursos del propio sitio.
• Actualiza las URLs guardadas en la base de datos (contenido del blog, campos de imagen).
• Confirma que el recurso externo existe en HTTPS: cambiar solo el esquema no sirve si el servidor de destino no responde por TLS.
• Como red de seguridad, la cabecera Content-Security-Policy: upgrade-insecure-requests pide al navegador que reescriba todas las peticiones a HTTPS.

La consola del navegador (pestaña Console, en las herramientas de desarrollo) lista cada recurso bloqueado o actualizado. Si el aviso persiste incluso sin contenido mixto, el problema puede ser el certificado: mira errores de certificado SSL.

¿Cuándo sigue siendo aceptable el HTTP puro?#

En desarrollo local (http://localhost) y en redes internas privadas, HTTP es habitual y Chrome no aplica el aviso a las direcciones privadas. En cualquier servicio accesible desde internet público, lo estándar es HTTPS, también para APIs, webhooks y paneles: el webhook de un bot, por ejemplo, suele exigir una URL HTTPS.

Cómo hacerlo en Square Cloud#

Toda aplicación web en Square Cloud recibe un subdominio *.squareweb.app con HTTPS en todos los planes. El TLS es automático: un certificado DV se emite y se renueva solo, así que no generas ni renuevas certificados.

Para usar tu propio dominio (a partir del plan Standard), creas en tu registrador los registros DNS que muestra el panel y sigues el estado de validación en tiempo real. El TLS se aprovisiona automáticamente, y el dominio sigue registrado a tu nombre en tu registrador.

La red incluye CDN Anycast, HTTP/3 y WAF, y redirige HTTP a HTTPS. Las cabeceras de tu aplicación, como HSTS, pasan intactas y siguen bajo tu control en el código. Mira el paso a paso en dominios personalizados, el funcionamiento de la red en red y CDN y, para varias apps en el mismo dominio, load balancing.