Unha páxina HTTPS que carga scripts por HTTP fai dúas peticións con dous niveis de protección distintos, e o cadeado só describe a primeira. Un túnel non cambia iso, porque protexe o portador e non o esquema propio do recurso. O navegador xa che di que petición fallou, se les a consola en lugar da barra de enderezos. Tres comprobacións levanche dunha páxina que funciona a medias a unha reparación real.

Le a petición, non a barra de enderezos

Un documento obtido por HTTPS pode referenciar un script, unha folla de estilo, unha fonte ou un marco por HTTP simple. Esa referencia é unha petición aparte, e é a que o navegador denuncia. A protección do documento principal non viaxa cara a dentro, e o túnel que transporta ambos fluxos non altera ningún dos dous esquemas. A páxina pode, por tanto, ser xenuinamente segura e xenuinamente rota á vez.

Chamar ao recurso simplemente un ficheiro incluído non fai que substituílo sexa inofensivo.

Se o contido dun script inseguro pode alterarse en tránsito e logo executarse, pode cambiar o comportamento da páxina, o que é un problema maior ca un fallo cosmético. As imaxes levan un risco menor pero real cando se modifican polo camiño. O cadeado non mente sobre nada. Responde a unha pregunta máis estreita ca a que lle fixeches.

Sabes que recursos se bloquean e cales se elevan

Os navegadores non tratan igual todos os tipos de recurso. a guía sobre contido mixto separan as peticións que se elevan a HTTPS das que se bloquean de vez, cos scripts, as follas de estilo e as peticións programáticas do lado bloqueado, mentres que as imaxes e os medios poden elevarse ou marcarse no seu lugar.

Esa diferenza explica os informes confusos. Unha páxina cun script bloqueado perde unha función por completo, mentres que unha páxina cunha imaxe elevada parece ben e cambiou a súa petición en silencio. As categorías documentadas tamén teñen excepcións, así que non supoñas que toda URL dun tipo dado se elevará con éxito. Le o que di a consola sobre a petición concreta en lugar de razoar a partir dunha extensión de ficheiro.

Un widget bloqueado non é proba de que o túnel fallase. É proba de que o navegador fixo o seu traballo.

Repara a referencia na súa orixe

Para o propietario do sitio, a reparación pertence ao lugar onde se escribiu a URL insegura: un modelo, unha folla de estilo, un script que monta URL ou un compoñente de terceiros. Cambiar o enderezo visible da páxina deixa todo iso intacto. Busca o host na orixe e repara cada referencia, non só a que a consola mencionou por casualidade.

Despois confirma que o recurso se serve de verdade por HTTPS con identidade válida, porque un cambio de esquema non pode facer aparecer un servizo que nunca se publicou alí.

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

Segue tamén as redireccións, porque unha referencia que comeza por HTTPS aínda pode acabar nunha vía de entrega en texto simple. Cando unha dependencia simplemente non ten entrega segura dispoñible, elimínaa ou substitúea polo proceso de cambio habitual en lugar de enviar unha solución provisional. Para o usuario, deixa as proteccións do navegador activadas e informa o propietario do sitio da URL do recurso, do seu tipo e da mensaxe da consola. Nunca difundas instrucións que pidan ao persoal permitir contido inseguro para unha páxina, porque esa excepción sobrevive ao incidente que a provocou.

Proba a páxina de novo tal como os usuarios a tocan

Exercita as operacións que cargan recursos baixo demanda, non só o primeiro documento. As páxinas traen código, datos e descargas adicionais tras premer un botón, e esas peticións adoitan ser as inseguras. Confirma as peticións concretas e o comportamento visible coa protección aínda activada. Unha proba que comeza cun perfil de navegador relaxado non che pode mostrar o que ve un usuario normal.

O túnel segue tendo o seu propio traballo, e ese traballo é o acceso á rede, non a integridade da páxina.

Unha vez que o tráfico sae do extremo do túnel, calquera petición HTTP restante non gañou nada do portador. Repara a ruta do recurso e mantén a aplicación no navegador. Tratar outra capa de transporte como reparación dunha dependencia insegura é como un equipo acaba cun script de atención ao usuario que desactiva o control que funcionaba correctamente.

Artigos relacionados