Qué tipo de problemas? Al navegador le importa poco donde estén ubicados los archivos no?. Hace peticiones indiscriminadamente a los recursos para obtenerlos si no hay cabeceras o políticas en el fuente que se lo impidan. Si no los encuentra por https:// puede que opte por intentar obtener el recurso por http:// y un intermediario intercepte la petición. Se podrían realizar ataques de denegación al cliente para forzar al navegador la obtención de recursos por un canal inseguro. Si esto no es correcto corrígueme por favor. Lo leí en algún sitio, igual lo malinterpreté.
No todos los recursos están disponibles por HTTPS y a veces no tienes control sobre estos recursos. Técnicamente, los navegadores todavía siguen pidiendo por la versión HTTP por defecto si no escribes el protocolo HTTPS. Lo que hace la gente es dejar el servicio HTTP para redirigir a HTTPS y usar HSTS para que la proxima vez que escribas el dominio sin el protocolo ya no use HTTP.
Pero técnicamente sí, el usuario es vulnerable la primera vez que hace la petición a un dominio sin escribir HTTPS. O al menos mi navegador funciona de está forma, no veo ninguna petición por HTTPS cuando pruebo mi dominio. Fuera de eso, no creo que ningún navegador debería intentar cargar recursos por medios inseguros a menos que se haya estipulado así. Mucho menos si la carga inicial del documento fue por HTTPS (por eso tenemos todo ese rollo de mixed content).
Incluso cuando usas upgrade-insecure-requests, si la petición falla por HTTPS no se realiza por HTTP. Yo diría que es una vulnerabilidad grave intentar cargar un recurso por otro medio que no sea seguro.
Autor
En línea
