¿Por qué una sola imagen http:// rompe la seguridad de toda la página, y no solo la de esa imagen?

Porque esa única solicitud no está cifrada ni autenticada, un atacante en la misma red (wifi público, un router comprometido) puede interceptarla o alterarla en tránsito, y dependiendo de qué sea (un script, en particular), eso puede comprometer el resto de la página aunque todo lo demás se haya cargado correctamente por HTTPS.

¿El navegador bloquea el contenido mixto automáticamente, o solo advierte?

Depende del tipo de recurso. El contenido mixto "activo" (scripts, hojas de estilos, iframes) se bloquea directamente en los navegadores modernos. El contenido mixto "pasivo" (imágenes, video, audio) normalmente aún se carga, pero activa una advertencia de candado roto en la barra de direcciones, que es exactamente el tipo de señal de confianza que hace dudar a los visitantes.

¿Cómo encuentra Scanverra el contenido mixto? ¿Simplemente escanea mi HTML en busca de enlaces http://?

No, es más robusto que eso. Scanverra carga la página en un navegador real y captura las solicitudes de red reales que hace la página, luego señala cualquier solicitud que empiece por http:// en una página servida por https. Eso detecta recursos cargados dinámicamente por JavaScript, no solo los codificados de forma fija en su marcado.

¿Puedo simplemente añadir upgrade-insecure-requests y dejar de preocuparme por las URL individuales?

Ayuda como red de seguridad: le indica al navegador que reescriba automáticamente las solicitudes http:// a https:// antes de enviarlas, pero solo funciona si el recurso está realmente disponible por HTTPS en ese mismo host. Es un buen respaldo, no un sustituto de arreglar las URL codificadas de forma fija.

Cómo solucionar las advertencias de contenido mixto

El contenido mixto ocurre cuando una página servida por HTTPS carga incluso un solo recurso (un script, una imagen, una hoja de estilos, un iframe) por HTTP simple en su lugar. Esa única solicitud sin cifrar socava la garantía de seguridad que el resto de la página estaba ofreciendo, y los navegadores responden bloqueando el recurso, rompiendo el icono del candado, o ambas cosas.

Por qué aparece el contenido mixto

URL http:// codificadas de forma fija que quedaron de antes de una migración a HTTPS. Marcado antiguo, contenido del CMS, o una base de datos de URL de activos almacenadas escritas cuando el sitio funcionaba con HTTP simple y nunca se actualizaron.
Contenido incrustado y widgets de terceros que todavía se sirven por HTTP. Una red publicitaria, un widget de comentarios, o un fragmento de analítica antiguo que nunca migró su propia entrega a HTTPS.
URL de CDN o de host de activos pasadas por alto durante una migración de protocolo. El dominio principal se trasladó a HTTPS, pero un subdominio o un host de activos de terceros que sirve imágenes o fuentes no se actualizó al mismo tiempo.
Contenido generado por el usuario con enlaces HTTP pegados. Un usuario envía contenido (una publicación de foro, una reseña de producto, un campo del CMS) que contiene una URL de imagen o de contenido incrustado http:// que se renderiza tal cual.

Cómo identificar cada instancia

Scanverra detecta el contenido mixto cargando su página en un navegador real y capturando su actividad de red real: tanto la Prueba de navegador como el escaneo de seguridad señalan cualquier solicitud que empiece por http:// mientras la página misma se sirve por HTTPS. Como se basa en solicitudes de red realmente capturadas en lugar de un escaneo estático de su código fuente HTML, detecta recursos cargados dinámicamente por JavaScript después de que la página se renderiza, no solo los codificados de forma fija directamente en su marcado.

Cómo solucionarlo

1. Reemplace las URL http:// codificadas de forma fija por https://

Antes: una URL de imagen http:// codificada de forma fijatypescript

1<img src="http://cdn.example.com/testimonial-1.jpg" alt="Customer headshot" />

Después: servida por https, o relativa al protocolo si el host soporta ambostypescript

1<img src="https://cdn.example.com/testimonial-1.jpg" alt="Customer headshot" />

2. Añada upgrade-insecure-requests como respaldo

Esta directiva de CSP le indica al navegador que reescriba automáticamente cualquier solicitud http:// restante a https:// antes de enviarla, capturando las URL que se le pasaron por alto, aunque solo funciona si el recurso es genuinamente accesible por HTTPS en ese host:

Actualice automáticamente cualquier solicitud http:// perdida a https://typescript

1Content-Security-Policy: upgrade-insecure-requests

3. Audite específicamente el contenido incrustado de terceros

Los scripts y widgets de terceros son la fuente más común de contenido mixto que no controla directamente: revise la documentación de cada uno en busca de una URL de incrustación HTTPS, y elimine los que no ofrezcan una.

4. Depure o reescriba el protocolo en el contenido enviado por el usuario

Si los usuarios pueden enviar contenido que contiene URL, reescriba http:// a https:// en el momento del renderizado (o rechace el envío) en lugar de renderizar el protocolo que se haya pegado.

Cómo detecta Scanverra este problema

Tanto la Prueba de navegador de Scanverra como su escaneo de seguridad capturan las solicitudes de red reales de su página en un navegador en vivo y señalan cualquiera que empiece por http:// en una página servida por HTTPS: una verificación genuina en tiempo de ejecución contra el tráfico real, no una búsqueda de texto en su código fuente.