¿Qué sucede con los recursos que no se pueden actualizar a https (por ejemplo, un certificado no válido)? ¿Serán bloqueados?

La solicitud se realizará a través de HTTPS. Si la solicitud falla, entonces falla. De lo contrario, el sistema se abriría para degradar los ataques, haciéndolo inútil frente a un atacante MITM.

Este comportamiento se especifica en el Fetch Standard del WHATWG (que se hace referencia en la especificación de solicitudes de actualización-inseguras-):

  

3. Solicitud de actualización a una URL potencialmente segura, si corresponde.
  

Dado que este paso se realiza antes de que se realicen las solicitudes de red reales, el resto del proceso se comporta exactamente como si la solicitud se hiciera originalmente como HTTPS desde el principio.

  

¿Qué tipo de violaciones se informarán contra el punto final especificado por report-uri en la política? ¿Solo actualizaciones fallidas o también actualizaciones exitosas?

No se notificarán infracciones mediante una directiva CSP con upgrade-insecure-requests . Según la especificación :

  

La supervisión de la directiva upgrade-insecure-request no tiene ningún efecto: la directiva se ignora cuando se envía a través de un Content-Security- Encabezado de solo informe de política . Los autores pueden determinar si las URL originales de los recursos actualizados fueron inseguras a través de Contenido-Seguridad-Política-Informe Solo . Por ejemplo, Content-Security-Policy-Report-Only : default-src https:; report-uri /endpoint . Consulte §3.4 Actualizaciones de informes para obtener detalles adicionales.

Por lo tanto, si desea obtener información sobre qué solicitudes se están actualizando mediante CSP, debe usar un error de disco duro (no upgrade-insecure-requests ) con el encabezado Report-Only.

Sección 3.4 explica esto con más detalle en el ejemplo 9:

  

Dentro del contexto de un recurso protegido que contiene la imagen insegura <img src="http://example.com/image.png">yentregalossiguientesencabezadosHTTP:

Content-Security-Policy:upgrade-insecure-requests;default-srchttps:Content-Security-Policy-Report-Only:default-srchttps:;report-uri/endpoint

    

Elagentedeusuarioiniciaráunasolicituddesolicitudque:

    

1. Violalapolíticaqueseestásupervisando,porloqueentregauninformedeviolacióna/endpoint.
  
2. Seactualizóde enlace a enlace .
  
3. No viola la política que se está aplicando.
  

Tenga en cuenta que el punto 3 aquí es clave. Dado que la solicitud se actualizó en el paso 2, la solicitud no "viola la política que se está aplicando". Según la especificación de CSP , solo se informan violaciones de la política de CSP:

  

Cuando se violan una o más de las directivas de una política, se puede generar un informe de violación y enviarlo a un punto final de informes asociado con la política.

1. ¿Qué sucede si falla una actualización?

Exactamente lo mismo que sucedería si fallara una solicitud HTTPS no actualizada. La especificación habla sobre las solicitudes de reescritura . Exactamente cómo se hace esto se explica en la sección 4.1 de la especificación, pero la esencia es que http:// se reemplaza con https:// . Eso significa que una vez que se reescribe la solicitud, es indistinguible de una solicitud que fue HTTPS desde el principio.

Para ser honesto, no puedo encontrar ninguna buena sección de la especificación para citar dónde queda claro. Pero los ejemplos uno y tres muestran directamente que este es el caso.

2. ¿Qué se informará?

No hay actualizaciones exitosas, no hay actualizaciones fallidas, nada. De la sección 3.1 de la especificación:

  

La supervisión de la directiva upgrade-insecure-requests no tiene ningún efecto: la directiva se ignora cuando se envía a través de un encabezado Content-Security-Policy-Report-Only .