Contenido mixto detrás de una VPN: repara el recurso, no el túnel

Una página HTTPS que carga scripts por HTTP hace dos peticiones con dos niveles de protección distintos, y el candado solo describe la primera. Un túnel no cambia eso, porque protege al portador y no el esquema propio del recurso. El navegador ya te dice qué petición falló, si lees la consola en lugar de la barra de direcciones. Tres comprobaciones te llevan de una página que funciona a medias a una reparación real.

Lee la petición, no la barra de direcciones

Un documento obtenido por HTTPS puede referenciar un script, una hoja de estilo, una fuente o un marco por HTTP simple. Esa referencia es una petición aparte, y es la que el navegador denuncia. La protección del documento principal no viaja hacia dentro, y el túnel que transporta ambos flujos no altera ninguno de los dos esquemas. La página puede, por tanto, ser genuinamente segura y genuinamente rota a la vez.

Llamar al recurso simplemente un archivo incluido no hace que sustituirlo sea inofensivo.

Si el contenido de un script inseguro puede alterarse en tránsito y luego ejecutarse, puede cambiar el comportamiento de la página, lo que es un problema mayor que un fallo cosmético. Las imágenes conllevan un riesgo menor pero real cuando se modifican de camino. El candado no miente sobre nada. Responde a una pregunta más estrecha que la que le hiciste.

Sabe qué recursos se bloquean y cuáles se elevan

Los navegadores no tratan igual todos los tipos de recurso. la guía sobre contenido mixto separan las peticiones que se elevan a HTTPS de las que se bloquean de plano, con los scripts, las hojas de estilo y las peticiones programáticas del lado bloqueado, mientras que las imágenes y los medios pueden elevarse o marcarse en su lugar.

Esa diferencia explica los informes confusos. Una página con un script bloqueado pierde una función por completo, mientras que una página con una imagen elevada se ve bien y ha cambiado su petición en silencio. Las categorías documentadas también tienen excepciones, así que no supongas que toda URL de un tipo dado se elevará con éxito. Lee lo que dice la consola sobre la petición concreta en lugar de razonar a partir de una extensión de archivo.

Un widget bloqueado no es prueba de que el túnel haya fallado. Es prueba de que el navegador hizo su trabajo.

Repara la referencia en su origen

Para el propietario del sitio, la reparación pertenece al lugar donde se escribió la URL insegura: una plantilla, una hoja de estilo, un script que arma URL o un componente de terceros. Cambiar la dirección visible de la página deja todo eso intacto. Busca el host en el código y repara cada referencia, no solo la que la consola mencionó por casualidad.

Después confirma que el recurso se sirve de verdad por HTTPS con identidad válida, porque un cambio de esquema no puede hacer aparecer un servicio que nunca se publicó ahí.

grep -rn "http://assets.example" ./templates
curl -sSI https://assets.example/widget.js | head -n 1

Sigue también las redirecciones, porque una referencia que empieza por HTTPS aún puede acabar en una vía de entrega en texto plano. Cuando una dependencia simplemente no tiene entrega segura disponible, elimínala o sustitúyela mediante el proceso de cambio habitual en lugar de enviar una solución provisional. Para el usuario, deja las protecciones del navegador activadas y informa al propietario del sitio de la URL del recurso, su tipo y el mensaje de la consola. Nunca difundas instrucciones que pidan al personal permitir contenido inseguro para una página, porque esa excepción sobrevive al incidente que la provocó.

Vuelve a probar la página tal como los usuarios la tocan

Ejercita las operaciones que cargan recursos bajo demanda, no solo el primer documento. Las páginas traen código, datos y descargas adicionales tras pulsar un botón, y esas peticiones suelen ser las inseguras. Confirma las peticiones concretas y el comportamiento visible con la protección aún activada. Una prueba que empieza con un perfil de navegador relajado no puede mostrarte lo que ve un usuario normal.

El túnel sigue teniendo su propio trabajo, y ese trabajo es el acceso a la red, no la integridad de la página.

Una vez que el tráfico sale del extremo del túnel, cualquier petición HTTP restante no ha ganado nada del portador. Repara la ruta del recurso y mantén la aplicación en el navegador. Tratar otra capa de transporte como reparación de una dependencia insegura es como un equipo acaba con un script de atención al usuario que desactiva el control que funcionaba correctamente.