Aquí tratamos dos temas que se confunden con frecuencia:

  • Mixed content (contenido mixto): una página cargada por HTTPS intenta cargar recursos (scripts, CSS, iframes, imágenes, etc.) por HTTP. Eso rompe la promesa de confidencialidad e integridad de HTTPS porque esos subrecursos pueden verse o modificarse en tránsito. MDN lo define como páginas “cargadas de forma segura” que usan recursos por HTTP u otro protocolo inseguro, y advierte que esos recursos pueden ser vistos o modificados por un atacante.
  • Enlaces <a href="http://…">: no siempre generan mixed content, porque al hacer clic el navegador navega a otra página (no carga un subrecurso dentro del mismo documento). web.dev lo explica claramente: ver http:// en href de <a> “a menudo no es un problema de contenido mixto”, con excepciones cuando scripts convierten ese enlace en carga embebida (p. ej., lightbox).

Conclusión: el mixed content suele ser un problema de seguridad y funcionamiento (porque el navegador puede bloquear recursos), mientras que los enlaces a http:// suelen ser un problema de degradación (downgrade), confianza, privacidad y consistencia, con excepciones técnicas que los convierten en mixed content.

📌 Guía completa: Seguridad WordPress (checklist + prioridades).

✅ Acción rápida: Iniciar auditoría gratis y recibir evidencias en minutos.

2) Mixed content en HTTPS: cómo ocurre y por qué “rompe” seguridad

2.1 Qué pasa técnicamente

En una página HTTPS, el navegador espera que todo lo que se cargue dentro del documento viaje por un canal seguro. Si un subrecurso se pide por HTTP, ese request queda expuesto a ataques de tipo man-in-the-middle (MITM):

  • El atacante puede leer el contenido (filtración).
  • O puede modificar el recurso antes de que llegue al usuario (inyección).

OWASP lo resume de forma directa: una página disponible por TLS no debería incluir recursos cargados por HTTP, porque esos recursos sin cifrar permiten sniffing o inyección de código.

2.2 Por qué rompe la seguridad “aunque el sitio tenga candado”

El candado del navegador representa la seguridad del contexto. Basta un subrecurso HTTP para romper la cadena de confianza. Por eso los navegadores:

  • intentan actualizar algunos tipos de recursos a HTTPS, o
  • directamente bloquean los que pueden comprometer la página.

MDN describe este enfoque: contenido “actualizable” se intenta llevar a HTTPS; contenido “bloqueable” se bloquea.

3) Tipos de mixed content y comportamiento de navegadores

La clasificación moderna se centra en el impacto:

  • Mixed content “bloqueable” (alto riesgo): recursos que pueden cambiar el comportamiento o el DOM (por ejemplo: JavaScript, CSS, iframes). Estos suelen bloquearse porque pueden comprometer toda la página.
  • Mixed content “actualizable” (riesgo más acotado): recursos como imágenes/audio/video que algunos navegadores intentan “autoupgrade” a HTTPS y, si falla, no los cargan. Chromium documenta este comportamiento (autoupgrade desde M80 para ciertos subrecursos).

Implicación operativa: aunque “parezca que funciona” (porque el navegador autoupgradea algunos recursos), seguimos teniendo:

  • riesgo de roturas intermitentes (si el recurso no existe en HTTPS),
  • y deuda técnica que reaparece con cambios de navegador/CDN/proveedor.

4) Detección y evidencia: cómo localizar el origen exacto

4.1 DevTools (método rápido y preciso)

  1. Abrimos la página en Chrome/Edge/Firefox.
  2. DevTools → Console y Network.
  3. Filtramos por http:// y por “Mixed Content”.

web.dev recomienda construir una lista de URLs HTTP + la página donde aparecen, y recuerda que los errores se muestran por página y la consola se limpia al navegar.

4.2 Búsqueda por patrones (método escalable)

  • Buscar http:// en plantillas, bundles, CSS, JS, y en el contenido del CMS.
  • Revisar especialmente:
    • URLs hardcodeadas,
    • recursos de terceros,
    • embeds,
    • y rutas de imágenes insertadas con URL absoluta.

web.dev advierte que en CMS es común que se inserten enlaces inseguros al publicar (por ejemplo, imágenes con URL completa en lugar de ruta relativa).

4.3 Informes CSP (método enterprise)

Para sitios grandes, la forma profesional de “no perseguir fantasmas” es habilitar reportes CSP y recolectar violaciones de mixed content en un endpoint de logging. web.dev sugiere CSP para rastrear mixed content a escala y para proteger mientras se migra (modo report-only y luego enforcement).

5) Solución de mixed content: correcciones en origen (prioridad)

La regla base es simple: no parcheamos el síntoma si podemos corregir la causa.

5.1 Sustituir HTTP por HTTPS (cuando el recurso soporta HTTPS)

Ejemplo reproducible (HTML):

<!-- MAL -->
<script src="http://cdn.ejemplo.com/app.js"></script>

<!-- BIEN -->
<script src="https://cdn.ejemplo.com/app.js"></script>

Criterio: si el proveedor no ofrece HTTPS, no es aceptable cargar ese recurso dentro de una página HTTPS (se rompe el modelo de seguridad).

5.2 Usar URLs relativas o “scheme-relative” con cautela

  • Preferimos relativas cuando el recurso vive en el mismo origen:
    • src="/assets/app.js"
  • Evitamos //dominio/... salvo casos muy controlados (puede heredar HTTP si el contexto no es estrictamente HTTPS).

5.3 Corregir en el CMS (WordPress u otros)

Los orígenes típicos de mixed content en CMS son:

  • imágenes insertadas con http://,
  • embeds o iframes antiguos,
  • constructores visuales que guardan URLs absolutas,
  • widgets/shortcodes.

Enfoque seguro: corregir en base de datos/contenido, y luego bloquear reintroducción (ver sección CSP y checklist).

6) Mitigación a escala: CSP (report-only, upgrade y bloqueo)

Cuando tenemos cientos/miles de URLs históricas, CSP es una herramienta de transición.

6.1 upgrade-insecure-requests (migración controlada)

Esta directiva instruye al navegador a tratar URLs inseguras como si se hubieran reemplazado por HTTPS. MDN indica que está pensada para sitios con muchas URLs legacy que necesitan reescritura.

Uso recomendado:

  • Primero en Report-Only para observar qué se rompería.
  • Luego en enforcement si el impacto está controlado.

6.2 block-all-mixed-content (enforcement estricto)

Evita cargar cualquier asset por HTTP cuando la página usa HTTPS; bloquea todo mixed content, incluyendo el “actualizable”.

Advertencia profesional: esto puede romper elementos visuales si aún quedan URLs HTTP. Por eso, lo usamos cuando ya hemos limpiado el sitio o cuando aceptamos roturas como señal para corregir rápidamente.

6.3 Qué CSP NO sustituye

CSP ayuda, pero no reemplaza:

  • limpieza real del contenido,
  • control de terceros,
  • y gobernanza editorial (evitar que se publique nuevo http://).

7) Enlaces <a> hacia http://: impacto, matices y casos habituales

Como dijimos, no suelen ser mixed content por sí mismos. web.dev lo aclara, y también señala una excepción relevante: algunos scripts interceptan <a> (por ejemplo, galerías/lightbox) y cargan el recurso dentro de la página, lo que sí puede convertirse en mixed content.

7.1 Impacto principal: degradación a HTTP (downgrade) y pérdida de garantías

Si el usuario hace clic y termina en HTTP:

  • la navegación queda sin cifrado,
  • y el contenido/credenciales pueden quedar expuestos en tránsito.

Aquí entra un control clave: HSTS. MDN explica que Strict-Transport-Security indica al navegador que ese host debe accederse solo por HTTPS y que futuros intentos por HTTP se actualicen automáticamente a HTTPS.
Esto significa que si el destino tiene HSTS correctamente configurado, incluso un enlace http://destino tenderá a terminar en HTTPS (en navegadores que ya han visto el header).

7.2 Impacto de privacidad: Referer y fugas de información

Si enlazamos a terceros (sea HTTP o HTTPS), la navegación puede enviar información de referente (cabecera Referer) y la política se controla con Referrer-Policy. MDN describe Referrer-Policy como el mecanismo para determinar qué datos de referente se incluyen con las solicitudes.
web.dev recomienda establecer explícitamente políticas más privadas como strict-origin-when-cross-origin.

Punto práctico: enlaces a http:// no solo degradan cifrado; también tienden a ser incoherentes con políticas modernas de privacidad y seguridad del navegador.

7.3 Casos habituales (reproducibles) de enlaces HTTP

  • Menús o footer con enlaces antiguos (http:// quedó “grabado” tras migrar a HTTPS).
  • Botones de “descargar” que apuntan a un recurso interno por http://.
  • Enlaces a recursos de terceros que solo ofrecían HTTP en el pasado.
  • Contenido copiado/pegado desde fuentes antiguas que traen el esquema HTTP.

8) Corrección de enlaces HTTP: estrategia segura (sin roturas)

8.1 Clasificación previa (para no romper)

Antes de reemplazar masivamente, clasificamos:

  1. Enlaces internos al mismo dominio
  • Deben ser HTTPS (y preferiblemente relativos).
  • Aquí HSTS + redirección 301 ayudan, pero no justifican mantener HTTP en el contenido.
  1. Enlaces a terceros
  • Verificamos si existe HTTPS equivalente.
  • Si no existe, debemos decidir: ¿es aceptable enlazar a un destino inseguro? En sitios serios, normalmente no.
  1. Enlaces usados por scripts (excepción web.dev)
  • Si hay lightbox/galería/JS que intercepta el click y “carga dentro”, tratamos el enlace como potencial mixed content y lo corregimos con prioridad.

8.2 Corrección recomendada (por orden)

  • Sustituir http:// → https:// cuando el destino lo soporte.
  • Para internos: preferir URLs relativas para evitar reintroducción.
  • Revisar redirecciones y canónicos para evitar cadenas innecesarias.

8.3 Controles de prevención

  • HSTS en el dominio propio para evitar downgrade y mejorar consistencia.
  • Referrer-Policy explícita para controlar fugas de información hacia terceros.
  • Gobernanza editorial: reglas del CMS para no insertar http:// en media/enlaces nuevos.

9) Checklist de cierre y validación post-corrección

Evidencia de “mixed content = 0”

  • DevTools Console/Network sin advertencias de mixed content (en páginas críticas).
  • Barrido por http:// en plantillas/assets/contenido (y lista de excepciones justificadas).
  • Si el sitio es grande: CSP Report-Only sin reportes de mixed content residuales.

Evidencia de “enlaces HTTP controlados”

  • No hay enlaces internos a http:// (preferimos relativos o https).
  • Enlaces externos validados: o migrados a HTTPS o retirados/alternativizados.
  • Strict-Transport-Security configurado en el dominio propio (cuando el sitio ya está plenamente en HTTPS).
  • Referrer-Policy definida explícitamente (mínimo strict-origin-when-cross-origin o más estricta según contexto).

10) FAQs

¿Por qué el navegador “bloquea” cosas si solo es una imagen?

Porque cualquier request HTTP dentro de una página HTTPS rompe el modelo de “todo cifrado”. Los navegadores han evolucionado hacia bloquear y/o autoupgradear para proteger al usuario. MDN describe el modelo de “upgrade o bloqueo” y Chromium documenta el autoupgrade para algunos subrecursos.

¿Un enlace <a href="http://..."> es mixed content?

Normalmente no, porque es navegación a otra página. web.dev lo recalca y añade excepciones cuando scripts interceptan el enlace y cargan el recurso dentro del documento.

¿Podemos “arreglar todo” solo con CSP upgrade-insecure-requests?

Es una herramienta de migración útil, pero no sustituye la corrección en origen. MDN indica que está orientada a sitios con muchas URLs legacy, y conviene tratarla como puente, no como destino final.