Nuova richiesta di autorizzazione per l'accesso alla rete locale

Chris Thompson
Chris Thompson

Pubblicata: 9 giugno 2025

Nell'ambito della bozza della specifica Accesso alla rete locale, Chrome aggiungerà una nuova richiesta di autorizzazione per i siti che effettuano connessioni alla rete locale di un utente. Lo scopo è proteggere gli utenti dagli attacchi di CSRF (Cross-Site Request Forgery) che hanno come target router e altri dispositivi su reti private e ridurre la capacità dei siti di utilizzare queste richieste per creare la impronta della rete locale dell'utente.

Per capire in che modo questa modifica influisce sull'ecosistema web, il team di Chrome sta cercando il feedback degli sviluppatori che creano applicazioni web che si basano su connessioni alla rete locale di un utente o a software in esecuzione localmente sulla sua macchina. A partire da Chrome 138, puoi attivare queste nuove limitazioni andando a 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 capacità dei siti web di inviare richieste ai server sulla rete locale di un utente (inclusi i server in esecuzione localmente sulla macchina dell'utente), richiedendo all'utente di concedere l'autorizzazione del sito prima che queste richieste possano essere effettuate. La possibilità di richiedere questa autorizzazione è limitata ai contesti sicuri.

Una richiesta con il testo "Cerca e connettiti a qualsiasi dispositivo sulla rete locale".
Esempio di richiesta di autorizzazione di accesso alla rete locale di Chrome.

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

Quali tipi di richieste sono interessate?

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

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

Loopback è qualsiasi destinazione che 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 nella RFC3927 di IPv4, nel prefisso "Indirizzo locale univoco" (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.

Una rete pubblica è qualsiasi altra destinazione.

Poiché l'autorizzazione di accesso alla rete locale è limitata ai contesti sicuri e può essere difficile eseguire la migrazione dei dispositivi della rete locale a HTTPS, le richieste alla rete locale soggette a autorizzazione ora saranno esenti 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 è indirizzata 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",
});

Che 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 la nuova richiesta di autorizzazione impostando chrome://flags#local-network-access-check su "Attivato (blocco)". Questo supporta l'attivazione della richiesta di autorizzazione di accesso alla rete locale per le richieste avviate utilizzando l'API fetch() JavaScript, il caricamento delle risorse secondarie e la navigazione nel frame secondario.

Un sito demo è disponibile all'indirizzo https://local-network-access-testing.glitch.me/ per attivare diverse forme di richieste di accesso alla rete locale.

Problemi noti e limitazioni

  • Al momento, la nuova richiesta di autorizzazione è implementata solo su Chrome per computer. Stiamo lavorando attivamente al porting su Chrome per Android. (Monitorato su crbug.com/400455013.)
  • Le connessioni WebSocket (crbug.com/421156866), WebTransport (crbug.com/421216834) e WebRTC (crbug.com/421223919) alla rete locale non sono ancora basate sull'autorizzazione LNA.
  • Al momento, le richieste di rete locale provenienti dai worker di servizio richiedono che all'origine del worker di servizio sia stata precedentemente concessa l'autorizzazione di accesso alla rete locale.
    • Se la tua applicazione effettua richieste alla rete locale da un service worker, attualmente dovrai attivare separatamente una richiesta alla 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. Consulta crbug.com/404887282.

Chrome 139 e versioni successive

Il nostro obiettivo è rilasciare l'accesso alla rete locale il prima possibile. Poiché alcuni siti potrebbero richiedere più tempo per essere aggiornati con le annotazioni di accesso alla rete locale, aggiungeremo una prova dell'origine per consentire ai siti di disattivare temporaneamente il requisito dei contesti sicuri prima di implementare l'accesso alla rete locale per impostazione predefinita. Questo dovrebbe fornire un percorso di migrazione più chiaro per gli sviluppatori, in particolare 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 in browser che non supportano ancora l'esenzione per i contenuti misti di accesso alla rete locale).

Aggiungeremo inoltre un criterio di Chrome Enterprise per controllare quali siti possono e non possono effettuare richieste di rete locale (preassegnando o prechiudendo l'autorizzazione a questi siti). In questo modo, le installazioni di Chrome gestite, come quelle nelle impostazioni aziendali, potranno evitare di mostrare l'avviso per i casi d'uso previsti noti o di 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, abbiamo in programma di implementare a breve l'accesso alla rete locale per le connessioni WebSocket, WebTransport e WebRTC.

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

Feedback richiesto

I feedback precedenti sullo sviluppo dell'accesso alla rete privata sono stati incredibilmente utili per indirizzarci verso il nostro nuovo approccio alle autorizzazioni di accesso alla rete locale. Vogliamo ringraziare ancora una volta tutti coloro che sono stati coinvolti nel corso degli anni.

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