Nuova richiesta di autorizzazione per l'accesso alla rete locale

Chris Thompson

Pubblicato: 9 giugno 2025

Chrome sta aggiungendo una nuova richiesta di autorizzazione per i siti che si connettono alla rete locale di un utente nell'ambito della specifica di accesso alla rete locale. L'obiettivo è proteggere gli utenti dagli attacchi di cross-site request forgery (CSRF) che prendono di mira router e altri dispositivi su reti private e ridurre la capacità dei siti di utilizzare queste richieste per identificare l'impronta della rete locale dell'utente.

Per capire l'impatto di questa modifica sull'ecosistema web, il team di Chrome sta cercando feedback dagli sviluppatori che creano applicazioni web che si basano sulla connessione alla rete locale di un utente o a software in esecuzione localmente sul computer dell'utente. A partire da Chrome 138, puoi attivare queste nuove limitazioni andando su chrome://flags/#local-network-access-check e impostando il flag su "Attivato (blocco)".

Che cos'è l'accesso alla rete locale?

L'accesso alla rete locale limita la possibilità dei siti web di inviare richieste ai server sulla rete locale di un utente (inclusi i server in esecuzione localmente sul computer dell'utente), richiedendo all'utente di concedere l'autorizzazione al sito prima che tali richieste possano essere effettuate. La possibilità di richiedere questa autorizzazione è limitata ai contesti sicuri.

Molte altre piattaforme, come Android, iOS e MacOS hanno un'autorizzazione di accesso alla rete locale. Ad esempio, potresti aver concesso questa autorizzazione per accedere alla rete locale all'app Google Home durante la configurazione di nuovi dispositivi Google TV e Chromecast.

Quali tipi di richieste sono interessati?

Per il primo traguardo dell'accesso alla rete locale, consideriamo una "richiesta di rete locale" qualsiasi richiesta dalla rete pubblica a una rete locale o a una destinazione di loopback.

Una rete locale è qualsiasi destinazione che si risolve nello spazio di indirizzi privati definito nella sezione 3 della RFC1918 in IPv4 (ad es. 192.168.0.0/16), un indirizzo IPv6 mappato in IPv4 in cui l'indirizzo IPv4 mappato è privato o un indirizzo IPv6 al di fuori delle subnet ::1/128, 2000::/3 e ff00::/8.

Il loopback è qualsiasi destinazione che si risolve nello spazio "loopback" (127.0.0.0/8) definito nella sezione 3.2.1.3 di RFC1122 di IPv4, nello spazio "link-local" (169.254.0.0/16) definito in RFC3927 di IPv4, nel prefisso "Unique Local Address" (fcc00::/7) definito nella sezione 3 di RFC4193 di IPv6 o nel prefisso "link-local" (fe80::/10) definito nella sezione 2.5.6 di RFC4291 di IPv6.

Per una mappatura completa degli indirizzi IP agli spazi di indirizzi, consulta la tabella nella specifica dell'accesso alla rete locale.

Una rete pubblica è qualsiasi altra destinazione.

Poiché l'autorizzazione di accesso alla rete locale è limitata ai contesti sicuri ed è difficile eseguire la migrazione dei dispositivi di rete locale a HTTPS, le richieste di rete locale con autorizzazione ora saranno esentate dai controlli dei contenuti misti se Chrome sa che le richieste verranno inviate alla rete locale prima di risolvere la destinazione. Chrome sa che una richiesta è destinata alla rete locale se:

• Il nome host della richiesta è un valore letterale IP privato (ad es. 192.168.0.1).
• Il nome host della richiesta è un dominio .local.
• La chiamata fetch() è annotata con l'opzione targetAddressSpace: "local".

// Example 1: Private IP literal is exempt from mixed content.
fetch("http://192.168.0.1/ping");

// Example 2: `.local` domain is exempt from mixed content.
fetch("http://router.local/ping");

// Example 3: Public domain is not exempt from mixed content,
// even if it resolves to a local network address.
fetch("http://example.com/ping");

// Example 4: Adding the `targetAddressSpace` option flags that
// the request will go to the local network, and is thus exempt
// from mixed content.
fetch("http://example.com/ping", {
  targetAddressSpace: "local",
});

Cosa cambia in Chrome

Chrome 138

La nostra versione iniziale dell'accesso alla rete locale è pronta per i test di attivazione in Chrome 138. Gli utenti possono attivare il nuovo prompt di autorizzazione impostando chrome://flags#local-network-access-check su "Attivato (blocco)". Questa supporta l'attivazione della richiesta di autorizzazione di accesso alla rete locale per le richieste avviate utilizzando l'API JavaScript fetch(), il caricamento delle risorse secondarie e la navigazione dei subframe.

Un sito demo è disponibile all'indirizzo https://lna-testing.notyetsecure.com/ per attivare diversi tipi di richieste di rete locale.

Problemi noti e limitazioni

• Le connessioni WebSocket (crbug.com/421156866), WebTransport (crbug.com/421216834) e WebRTC (crbug.com/421223919) alla rete locale non sono ancora controllate dall'autorizzazione LNA.
• Le richieste di rete locale da Service Worker e Shared Worker richiedono che all'origine del worker sia stata precedentemente concessa l'autorizzazione di accesso alla rete locale.
  • Se la tua applicazione effettua richieste di rete locale da un service worker, dovrai attivare separatamente una richiesta di rete locale dalla tua applicazione per attivare la richiesta di autorizzazione. Stiamo lavorando a un modo per consentire ai lavoratori di attivare la richiesta di autorizzazione se è disponibile un documento attivo. Vedi crbug.com/404887282.

Chrome 139 e versioni successive

Il nostro obiettivo è rendere disponibile l'accesso alla rete locale il prima possibile. Riconoscendo che alcuni siti potrebbero aver bisogno di tempo aggiuntivo per essere aggiornati con le annotazioni di accesso alla rete locale, aggiungeremo una Origin Trial per consentire ai siti di disattivare temporaneamente il requisito dei contesti sicuri prima di implementare l'accesso alla rete locale per impostazione predefinita. In questo modo, gli sviluppatori avranno un percorso di migrazione più chiaro, soprattutto se si basano sull'accesso alle risorse di rete locale tramite HTTP (poiché queste richieste verrebbero bloccate come contenuti misti se richieste da una pagina HTTPS nei browser che non supportano ancora l'esenzione per i contenuti misti dell'accesso alla rete locale).

Aggiungeremo anche un criterio aziendale di Chrome per controllare quali siti possono e non possono effettuare richieste di rete locale (concessione o negazione preventiva dell'autorizzazione a questi siti). In questo modo, le installazioni di Chrome gestite, ad esempio quelle in contesti aziendali, possono evitare di mostrare l'avviso per i casi d'uso noti e previsti oppure bloccare ulteriormente i siti e impedire loro di richiedere l'autorizzazione.

Prevediamo di continuare a integrare l'autorizzazione di accesso alla rete locale con diverse funzionalità che possono inviare richieste alla rete locale. Ad esempio, prevediamo di rendere disponibile a breve l'accesso alla rete locale per le connessioni WebSocket, WebTransport e WebRTC.

Forniremo maggiori informazioni man mano che ci avvicineremo al lancio completo dell'accesso alla rete locale in Chrome.

Feedback richiesto

I feedback precedenti sullo sviluppo dell'accesso alla rete privata sono stati estremamente preziosi per guidarci al nostro nuovo approccio di autorizzazione per l'accesso alla rete locale. Vorremmo ringraziare ancora una volta tutti coloro che sono stati coinvolti nel corso degli anni.

Se sviluppi o utilizzi un sito web che si basa sulla creazione di connessioni alla rete locale dell'utente o a un software in esecuzione localmente sul computer dell'utente, il team di Chrome è interessato al tuo feedback e ai tuoi casi d'uso. Puoi fare due cose per aiutarci:

• Vai a chrome://flags#local-network-access-check, imposta il flag su "Attivato (blocco)" e verifica se il tuo sito web attiva correttamente la nuova richiesta di autorizzazione (e funziona come previsto dopo che hai concesso l'autorizzazione).
• Se riscontri problemi o vuoi inviare un feedback, segnala un problema nel Issue Tracker di Chromium o nel nostro repository GitHub delle specifiche LNA. Chrome vorrebbe conoscere la tua opinione.