[{"data":1,"prerenderedAt":286},["ShallowReactive",2],{"blog-tag-it-security-header":3},{"tagName":4,"posts":5},"Security Header",[6,141],{"id":7,"title":8,"author":9,"body":10,"category":4,"date":107,"description":108,"extension":109,"faq":110,"meta":129,"navigation":130,"path":131,"readingTime":132,"seo":133,"slug":134,"stem":135,"tags":136,"__hash__":140},"blog\u002Fblog\u002Fit\u002Fwhat-is-cross-origin-opener-policy.md","Che cos'è l'header Cross-Origin-Opener-Policy e perché è importante?","EuroraCloud Team",{"type":11,"value":12,"toc":96},"minimark",[13,17,21,26,29,32,36,39,42,46,49,52,56,59,62,66,69,72,76,79,89,93],[14,15,8],"h1",{"id":16},"che-cosè-lheader-cross-origin-opener-policy-e-perché-è-importante",[18,19,20],"p",{},"L'header Cross-Origin-Opener-Policy, di solito scritto COOP, è un header di risposta che controlla se la tua pagina condivide una relazione di finestra con pagine di altre origini. Impostato su same-origin, isola il tuo documento in un proprio browsing context group, così che una pagina di un'altra origine che apre la tua, o che tu apri, non possa mantenere alcun riferimento scriptabile verso la tua finestra. Questo chiude una classe di attacchi cross-origin noti come XS-Leaks e attacchi side-channel, ed è inoltre l'impostazione che sblocca alcune potenti funzionalità del browser.",[22,23,25],"h2",{"id":24},"perché-esiste-lheader-cross-origin-opener-policy","Perché esiste l'header Cross-Origin-Opener-Policy?",[18,27,28],{},"COOP esiste perché l'apertura di una finestra crea un collegamento che può essere abusato. Quando una pagina ne apre un'altra con window.open(), o una pagina apre la tua, il browser può mantenere un riferimento tra le due finestre tramite la proprietà window.opener. Se queste due pagine provengono da origini diverse, quel riferimento diventa una via attraverso cui una pagina cross-origin può sondare la tua.",[18,30,31],{},"Gli attacchi che questo rende possibili sono sottili. Non rubano i tuoi dati direttamente, ma li deducono tramite side channel, timing e stato del browser condiviso, in una famiglia di tecniche che la comunità della sicurezza chiama XS-Leaks. Secondo la documentazione di Mozilla, COOP è stato introdotto proprio perché un sito possa garantire che il proprio documento di primo livello non condivida un browsing context group con documenti cross-origin, ed è esattamente ciò che recide quel riferimento e chiude la via.",[22,33,35],{"id":34},"che-cosa-fa-davvero-lheader-cross-origin-opener-policy","Che cosa fa davvero l'header Cross-Origin-Opener-Policy?",[18,37,38],{},"COOP decide se il tuo documento e le pagine con cui interagisce appartengono allo stesso browsing context group, il concetto interno al browser che determina se due finestre possono scriptarsi a vicenda. Quando lo imposti in modo rigoroso, la tua finestra entra in un proprio gruppo e ogni finestra cross-origin perde il suo riferimento verso la tua.",[18,40,41],{},"L'header ha un piccolo insieme di valori. Il valore predefinito, unsafe-none, non applica alcun isolamento e lascia che il tuo documento condivida un browsing context group con pagine cross-origin. Il valore rigoroso, same-origin, isola il tuo documento in modo che solo le pagine della stessa origine che impostano anch'esse same-origin possano restare nello stesso gruppo. Un valore intermedio, same-origin-allow-popups, mantiene quell'isolamento ma lascia funzionare normalmente i popup che apri deliberatamente, la scelta pratica per i siti che dipendono da flussi tramite popup come il pagamento o il single sign-on. Quando una finestra cross-origin viene aperta sotto same-origin, il suo window.opener diventa null, così il riferimento semplicemente non esiste.",[22,43,45],{"id":44},"cosa-succede-se-non-lo-imposti","Cosa succede se non lo imposti?",[18,47,48],{},"Senza COOP il valore predefinito è unsafe-none, il che significa nessun isolamento e il riferimento di finestra che resta aperto. Una pagina cross-origin che apre la tua, o che tu apri, può mantenere una presa sulla tua finestra e usarla come punto d'appoggio per le tecniche side-channel descritte sopra.",[18,50,51],{},"Questa è una lacuna silenziosa, non rumorosa. Nulla sul tuo sito sembra rotto, e la maggior parte dei visitatori non la attiverà mai, ed è proprio per questo che spesso resta non affrontata. Ma per un sito che tratta qualcosa di sensibile, un login, un portale pazienti, un passaggio di pagamento, lasciare aperta la relazione di finestra è un'esposizione evitabile, ed è una che scanner di sicurezza e audit segnalano sempre più come header mancante.",[22,53,55],{"id":54},"come-implementi-lheader-cross-origin-opener-policy","Come implementi l'header Cross-Origin-Opener-Policy?",[18,57,58],{},"Imposti COOP come un singolo header di risposta HTTP. Per la maggior parte dei siti il valore di partenza giusto è Cross-Origin-Opener-Policy: same-origin-allow-popups, che ti dà l'isolamento preservando i flussi tramite popup; un sito senza tali dipendenze può passare al più rigoroso same-origin. Può essere aggiunto sul web server, nel livello applicativo, o al margine in un CDN o in un livello di sicurezza posto davanti al sito.",[18,60,61],{},"L'unica raccomandazione forte è: testa prima di imporre. COOP supporta una modalità report-only, inviata come Cross-Origin-Opener-Policy-Report-Only, che usa la Reporting API del browser per dirti cosa la policy romperebbe senza romperlo davvero. Eseguire prima in report-only, tenere d'occhio i flussi di popup o di finestra che verrebbero colpiti, e solo dopo passare all'header imposto è la via sicura, soprattutto su un sito con integrazioni di terze parti che non hai costruito tu.",[22,63,65],{"id":64},"cosa-cambia-sul-tuo-sito-una-volta-attivato","Cosa cambia sul tuo sito una volta attivato?",[18,67,68],{},"Per la maggior parte dei siti, nulla di visibile. I normali caricamenti di pagina, la navigazione e il comportamento same-origin non sono influenzati, e l'isolamento avviene in modo invisibile a livello di browser. Il vantaggio che ottieni è che le finestre cross-origin non possono più mantenere un riferimento verso la tua, il che rimuove la superficie di attacco senza toccare l'esperienza utente.",[18,70,71],{},"Il punto da controllare è qualsiasi flusso che apra deliberatamente un'altra origine o venga aperto da essa. Un fornitore di pagamenti, un identity provider, o uno strumento incorporato che comunica tramite riferimenti di finestra può essere colpito da un valore same-origin rigoroso, ed è proprio per questo che same-origin-allow-popups esiste e per cui il test in report-only conta. C'è anche un vantaggio che vale la pena conoscere: impostare same-origin, insieme all'header affine Cross-Origin-Embedder-Policy, porta il tuo documento in uno stato cross-origin isolated che alcune potenti funzionalità del browser richiedono, come SharedArrayBuffer e i timer ad alta risoluzione.",[22,73,75],{"id":74},"cosa-dovresti-fare-adesso","Cosa dovresti fare adesso?",[18,77,78],{},"Comincia col controllare se il tuo sito invia affatto un header Cross-Origin-Opener-Policy, perché l'assenza predefinita di header significa nessun isolamento. Se manca, la via a basso rischio è aggiungerlo in modalità report-only, confermare che nulla nei tuoi flussi di popup o di terze parti si rompa, e poi imporre same-origin-allow-popups come valore predefinito sensato, o same-origin se il tuo sito non ha dipendenze dai popup.",[18,80,81,82],{},"Se desideri che questo venga controllato e configurato correttamente su tutto il tuo sito anziché a pezzi, EuroraCloud può esaminare i tuoi security header attuali e mostrarti cosa risolve la nostra piattaforma. ",[83,84,88],"a",{"href":85,"rel":86},"https:\u002F\u002Fwww.euroracloud.eu\u002F?utm_source=blog&utm_medium=article&utm_campaign=coop",[87],"nofollow","Scopri cosa risolve EuroraCloud",[22,90,92],{"id":91},"conclusione-cosa-dovresti-portare-con-te-sullheader-cross-origin-opener-policy","Conclusione: cosa dovresti portare con te sull'header Cross-Origin-Opener-Policy?",[18,94,95],{},"COOP è un header silenzioso ma prezioso: isola la tua finestra del browser dalle pagine cross-origin, chiudendo una classe di attacchi side-channel e tramite popup che non lasciano alcun segno visibile finché uno scanner o un aggressore non li trova. Per la maggior parte dei siti la via sicura è testare in modalità report-only, poi imporre same-origin-allow-popups, che protegge la finestra preservando i flussi popup legittimi. Il passo più utile è controllare se il tuo sito invia l'header oggi, perché finché non lo fa, il valore predefinito è nessun isolamento.",{"title":97,"searchDepth":98,"depth":98,"links":99},"",2,[100,101,102,103,104,105,106],{"id":24,"depth":98,"text":25},{"id":34,"depth":98,"text":35},{"id":44,"depth":98,"text":45},{"id":54,"depth":98,"text":55},{"id":64,"depth":98,"text":65},{"id":74,"depth":98,"text":75},{"id":91,"depth":98,"text":92},"2026-07-13","L'header Cross-Origin-Opener-Policy permette a una pagina di isolare la propria finestra del browser dalle pagine cross-origin che la aprono o che vengono aperte da essa, chiudendo una classe di attacchi side-channel e tramite popup. Ecco cosa fa, come impostarlo e cosa cambia quando lo fai.","md",[111,113,115,118,120,123,126],{"question":25,"answer":112},"COOP esiste perché l'apertura di una finestra crea un collegamento scriptabile che può essere abusato. Quando una pagina ne apre un'altra, il browser può mantenere un riferimento tra le due finestre tramite window.opener, e se le pagine provengono da origini diverse, quel riferimento diventa una via attraverso cui una pagina cross-origin può sondare la tua tramite side channel e timing, una famiglia di tecniche nota come XS-Leaks. COOP permette a un sito di garantire che il proprio documento di primo livello non condivida un browsing context group con documenti cross-origin, il che recide quel riferimento.",{"question":35,"answer":114},"COOP decide se il tuo documento e le pagine con cui interagisce appartengono allo stesso browsing context group, il concetto interno al browser che determina se due finestre possono scriptarsi. Impostato in modo rigoroso, la tua finestra entra in un proprio gruppo e le finestre cross-origin perdono il loro riferimento verso la tua. I valori sono unsafe-none (predefinito, nessun isolamento), same-origin (isolamento rigoroso) e same-origin-allow-popups (isolamento che consente i popup che apri). Sotto same-origin, il window.opener di una finestra cross-origin diventa null.",{"question":116,"answer":117},"Cosa succede se non imposti l'header Cross-Origin-Opener-Policy?","Senza COOP il valore predefinito è unsafe-none, il che significa nessun isolamento e il riferimento di finestra che resta aperto. Una pagina cross-origin che apre la tua, o che tu apri, può mantenere una presa sulla tua finestra e usarla come punto d'appoggio per attacchi side-channel. Nulla sembra rotto, ed è per questo che resta non affrontato, ma per un sito con un login, un portale pazienti o un passaggio di pagamento è un'esposizione evitabile che gli scanner segnalano sempre più.",{"question":55,"answer":119},"Imposti COOP come un singolo header di risposta HTTP, sul web server, nel livello applicativo o al margine. Per la maggior parte dei siti il valore di partenza giusto è same-origin-allow-popups, che dà isolamento preservando i flussi tramite popup; un sito senza dipendenze dai popup può usare il più rigoroso same-origin. Testa prima di imporre usando la modalità report-only, inviata come Cross-Origin-Opener-Policy-Report-Only, che segnala cosa la policy romperebbe senza romperlo.",{"question":121,"answer":122},"Cosa cambia sul tuo sito una volta attivato l'header Cross-Origin-Opener-Policy?","Per la maggior parte dei siti non cambia nulla di visibile; i normali caricamenti di pagina e il comportamento same-origin non sono influenzati e l'isolamento avviene a livello di browser. Il punto da controllare è qualsiasi flusso che apra deliberatamente un'altra origine o venga aperto da essa, come un fornitore di pagamenti o di identità, ed è per questo che same-origin-allow-popups esiste e per cui il test in report-only conta. Impostare same-origin insieme a Cross-Origin-Embedder-Policy abilita anche uno stato cross-origin isolated che alcune potenti funzionalità come SharedArrayBuffer richiedono.",{"question":124,"answer":125},"Cosa dovresti fare adesso riguardo all'header Cross-Origin-Opener-Policy?","Controlla se il tuo sito invia un header Cross-Origin-Opener-Policy, perché nessun header significa nessun isolamento. Se manca, aggiungilo in modalità report-only, conferma che nulla nei tuoi flussi di popup o di terze parti si rompa, e poi imponi same-origin-allow-popups come valore predefinito sensato, o same-origin se il tuo sito non ha dipendenze dai popup.",{"question":127,"answer":128},"Cosa dovresti portare con te sull'header Cross-Origin-Opener-Policy?","COOP è un header silenzioso ma prezioso che isola la tua finestra del browser dalle pagine cross-origin, chiudendo una classe di attacchi side-channel e tramite popup che non lasciano alcun segno visibile. Per la maggior parte dei siti la via sicura è testare in modalità report-only, poi imporre same-origin-allow-popups, che protegge la finestra preservando i flussi popup legittimi. Il passo più utile è controllare se il tuo sito invia l'header oggi, perché finché non lo fa, il valore predefinito è nessun isolamento.",{},true,"\u002Fblog\u002Fit\u002Fwhat-is-cross-origin-opener-policy","7 minuti",{"title":8,"description":108},"what-is-cross-origin-opener-policy","blog\u002Fit\u002Fwhat-is-cross-origin-opener-policy",[137,4,138,139],"Cross-Origin-Opener-Policy","Sicurezza web","Isolamento del browser","j3mEIoS-l84dJhBX1N-NOdRJLd13oH80Q3zQjiOfDME",{"id":142,"title":143,"author":9,"body":144,"category":4,"date":107,"description":253,"extension":109,"faq":254,"meta":276,"navigation":130,"path":277,"readingTime":278,"seo":279,"slug":280,"stem":281,"tags":282,"__hash__":285},"blog\u002Fblog\u002Fit\u002Fwhat-is-permissions-policy.md","Che cos'è l'header Permissions-Policy e perché è importante?",{"type":11,"value":145,"toc":243},[146,149,152,156,159,162,166,179,185,189,192,195,197,200,203,207,210,213,216,218,221,224,226,229,236,240],[14,147,143],{"id":148},"che-cosè-lheader-permissions-policy-e-perché-è-importante",[18,150,151],{},"L'header Permissions-Policy è un header di risposta che permette a un sito web di controllare quali funzionalità del browser le sue pagine, e qualsiasi contenuto incorporato in esse, possono usare. Funzionalità come camera, microfono, geolocalizzazione e pagamento possono essere ciascuna consentite, limitate alla tua origine, o disattivate del tutto. Impostarlo significa che anche se uno script o una terza parte incorporata tenta di raggiungere una di quelle funzionalità, il browser rifiuta a meno che la tua policy non lo consenta, il che riduce sia la tua esposizione alla privacy sia la tua superficie di attacco.",[22,153,155],{"id":154},"perché-esiste-lheader-permissions-policy","Perché esiste l'header Permissions-Policy?",[18,157,158],{},"I browser moderni espongono molte potenti capacità alle pagine web: posizione, camera, microfono, sensori di movimento e altro. Qualsiasi script in esecuzione sulla tua pagina, inclusi gli script di terze parti che hai incorporato per analytics, chat o pubblicità, può in linea di principio chiedere al browser di usare quelle capacità. Permissions-Policy esiste perché tu possa dichiarare, a livello dell'intero sito, quali di quelle funzionalità sono consentite e per chi.",[18,160,161],{},"Lo scopo è chiudere il divario tra ciò che un browser può fare e ciò di cui il tuo sito ha davvero bisogno. La maggior parte dei siti web non usa mai l'accelerometro o la payment API, eppure senza una policy quelle funzionalità restano raggiungibili da qualsiasi codice sulla pagina. Secondo la documentazione di MDN, quando una policy blocca una funzionalità all'utente non viene nemmeno chiesto il permesso, e il tentativo di uno script di usarla semplicemente fallisce, che è esattamente il contenimento che vuoi per le funzionalità che non hai mai avuto intenzione di usare.",[22,163,165],{"id":164},"che-cosa-fa-davvero-lheader-permissions-policy","Che cosa fa davvero l'header Permissions-Policy?",[18,167,168,169,173,174,178],{},"L'header funziona come un elenco di direttive, una per funzionalità, ciascuna con una allowlist che indica quali origini possono usarla. La sintassi è il nome della funzionalità, un segno di uguale, e le origini consentite tra parentesi, con più direttive separate da virgole, ad esempio geolocation=(), camera=(self). Una allowlist vuota, scritta (), disattiva la funzionalità ovunque; self la consente solo sulla tua origine; un'origine specifica come (\"",[83,170,171],{"href":171,"rel":172},"https:\u002F\u002Fexample.com",[87],"\") consente quell'origine; e ",[175,176,177],"code",{},"*"," la consente ovunque, inclusi i frame incorporati.",[18,180,181,182,184],{},"Un dettaglio utile è che ogni funzionalità ha una allowlist predefinita che si applica quando non dici nulla, e a seconda della funzionalità quel valore predefinito è uno tra ",[175,183,177],{},", self o nessuno. Il valore di impostare l'header esplicitamente è quindi che smetti di affidarti ai valori predefiniti per funzionalità e prendi invece una decisione deliberata e uniforme: disattiva tutto ciò che non usi, e limita tutto ciò che usi alla tua origine o ai partner specifici che ne hanno bisogno.",[22,186,188],{"id":187},"come-si-comporta-lheader-con-gli-iframe-incorporati","Come si comporta l'header con gli iframe incorporati?",[18,190,191],{},"Questa è la parte su cui la maggior parte delle persone inciampa, quindi vale la pena essere precisi. Una funzionalità è disponibile all'interno di un iframe incorporato solo se sono soddisfatte due condizioni insieme: la tua pagina di primo livello deve consentire la funzionalità per l'origine di quel frame nella sua Permissions-Policy, e l'iframe stesso non deve averla disattivata. In altre parole, la pagina genitore fissa il confine esterno, e nulla di ciò che è incorporato può concedersi una funzionalità che la pagina genitore ha negato.",[18,193,194],{},"C'è anche un controllo per iframe che funziona insieme all'header, l'attributo allow sull'elemento iframe, ad esempio una mappa incorporata aggiunta con un frame il cui attributo allow consente geolocation. Il modello mentale da tenere è che l'header è la policy a livello di sito e l'attributo allow è l'eccezione per singola incorporazione al suo interno: il frame può ricevere solo ciò che l'header già consente, e l'attributo poi lo restringe o lo indirizza a quella specifica incorporazione. È esattamente per questo che un widget di terze parti a volte segnala che una funzionalità è bloccata anche se il codice del widget è corretto, perché la pagina contenitore non ha mai consentito quella funzionalità per l'origine del widget.",[22,196,45],{"id":44},[18,198,199],{},"Senza l'header, ogni funzionalità ricade sulla propria allowlist predefinita, che per diverse funzionalità è più permissiva di quanto un sito tipico richieda. In pratica questo significa che capacità che non usi mai restano raggiungibili, e che il contenuto di terze parti incorporato potrebbe essere in grado di richiedere funzionalità che non avresti concesso se ti fossero state chieste.",[18,201,202],{},"Di solito non è una falla urgente, ed è per questo che resta non affrontata, ma è reale. Pesa di più dove incorpori codice che non hai scritto: un tag di analytics, un widget di chat, un pixel di marketing. Limitare le funzionalità che non usi riduce ciò che tutto quel codice incorporato può tentare, ed è esattamente il tipo di header mancante che gli scanner di sicurezza e gli audit ora segnalano su quasi ogni sito che non lo ha impostato.",[22,204,206],{"id":205},"come-implementi-lheader-permissions-policy","Come implementi l'header Permissions-Policy?",[18,208,209],{},"Imposti Permissions-Policy come un singolo header di risposta HTTP. Una policy di partenza sensata è disattivare le funzionalità che sai di non usare e limitare il resto alla tua origine, ad esempio Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), per poi allentare singole direttive solo dove esiste un'esigenza reale. Può essere applicato sul web server, nel livello applicativo, o al margine in un CDN o in un livello di sicurezza davanti al sito.",[18,211,212],{},"Aiuta vederlo su un sito reale anziché in astratto. Prendi un sito di una clinica che mostra una mappa incorporata così che i pazienti trovino lo studio, e fa girare uno strumento di prenotazione online che apre un passaggio di pagamento, ma non ha altro uso delle funzionalità del browser. Una policy su misura per quel sito disattiverebbe tutto ciò che non tocca mai e consentirebbe solo ciò di cui quelle due funzioni hanno bisogno: geolocation limitata all'origine del fornitore della mappa, payment limitato al fornitore di prenotazione o pagamento, e camera, microfono e i vari sensori tutti disattivati con una allowlist vuota. Il risultato è una pagina in cui la mappa e il checkout funzionano esattamente come prima, mentre ogni altra capacità è semplicemente non disponibile per qualsiasi script, che sia tuo o di una terza parte incorporata. Il principio si generalizza: elenca ciò che il sito usa davvero, consentilo alle origini specifiche che lo forniscono, e chiudi il resto.",[18,214,215],{},"Testa prima di bloccarlo. L'header ha un compagno report-only, Permissions-Policy-Report-Only, che usa la Reporting API del browser per dirti cosa una policy bloccherebbe senza applicarla davvero. Eseguirlo prima è il modo sicuro per scoprire se una funzionalità reale, una mappa che ha bisogno di geolocation, uno strumento di prenotazione che apre un flusso di pagamento, un video incorporato, verrebbe catturata dalla tua policy, così da consentirla deliberatamente anziché romperla di sorpresa.",[22,217,65],{"id":64},[18,219,220],{},"Per la maggior parte dei siti, nulla di visibile. Le pagine normali che non usano funzionalità limitate si comportano esattamente come prima, e i visitatori non notano nulla, perché la policy interviene solo quando del codice tenta di raggiungere una funzionalità che non hai consentito.",[18,222,223],{},"Il punto da controllare è qualsiasi funzionalità su cui il tuo sito fa davvero affidamento, e qualsiasi cosa serva alle tue terze parti incorporate. Un localizzatore di negozi che usa geolocation, una funzione di videochiamata che usa camera e microfono, o un checkout che usa la payment API devono avere tutti le loro direttive impostate per consentire le origini giuste, che è precisamente perché il test in report-only conta prima dell'applicazione. Fai bene questo una volta e l'header tiene poi silenziosamente la linea, consentendo ciò che intendevi e rifiutando tutto il resto.",[22,225,75],{"id":74},[18,227,228],{},"Comincia col controllare se il tuo sito invia affatto un header Permissions-Policy, perché senza di esso ogni funzionalità ricade semplicemente sul suo valore predefinito. Se manca, la via a basso rischio è aggiungerlo in modalità report-only, elencare le funzionalità che usi davvero, confermare che nulla su cui fai affidamento venga bloccato, e poi applicare una policy che disattiva tutto il resto.",[18,230,231,232],{},"Se desideri che questo venga esaminato e configurato correttamente su tutto il tuo sito anziché a pezzi, EuroraCloud può controllare i tuoi security header attuali e mostrarti cosa risolve la nostra piattaforma. ",[83,233,88],{"href":234,"rel":235},"https:\u002F\u002Fwww.euroracloud.eu\u002F",[87],[22,237,239],{"id":238},"conclusione-cosa-dovresti-portare-con-te-sullheader-permissions-policy","Conclusione: cosa dovresti portare con te sull'header Permissions-Policy?",[18,241,242],{},"Permissions-Policy è un header silenzioso e pratico: ti permette di disattivare le funzionalità del browser che il tuo sito non usa mai e di limitare quelle che usa alle sole origini che ne hanno bisogno, così che né i tuoi script né le terze parti incorporate possano raggiungere capacità che non hai mai voluto esporre. Il modo sicuro di adottarlo è testare in modalità report-only, confermare che le tue funzionalità reali funzionino ancora, e poi applicare una policy che disattiva il resto. Il passo più utile è controllare se il tuo sito invia l'header oggi, perché finché non lo fa, ogni funzionalità resta sul suo valore predefinito.",{"title":97,"searchDepth":98,"depth":98,"links":244},[245,246,247,248,249,250,251,252],{"id":154,"depth":98,"text":155},{"id":164,"depth":98,"text":165},{"id":187,"depth":98,"text":188},{"id":44,"depth":98,"text":45},{"id":205,"depth":98,"text":206},{"id":64,"depth":98,"text":65},{"id":74,"depth":98,"text":75},{"id":238,"depth":98,"text":239},"L'header Permissions-Policy permette a un sito di decidere quali funzionalità del browser, come camera, microfono e geolocalizzazione, le sue pagine e i contenuti incorporati possono usare. Ecco cosa fa, come impostarlo e cosa cambia quando lo fai.",[255,257,259,262,265,267,270,273],{"question":155,"answer":256},"I browser moderni espongono capacità potenti come posizione, camera, microfono e sensori di movimento, e qualsiasi script sulla tua pagina, incluso codice di terze parti incorporato, può in linea di principio chiedere di usarle. Permissions-Policy esiste perché tu possa dichiarare a livello di sito quali funzionalità sono consentite e per chi, chiudendo il divario tra ciò che un browser può fare e ciò di cui il tuo sito ha bisogno. Quando una policy blocca una funzionalità all'utente non viene nemmeno chiesto e il tentativo di uno script semplicemente fallisce.",{"question":165,"answer":258},"L'header è un elenco di direttive, una per funzionalità, ciascuna con una allowlist di origini che possono usarla. La sintassi è il nome della funzionalità, un segno di uguale, e le origini consentite tra parentesi, con direttive separate da virgole, ad esempio geolocation=(), camera=(self). Una allowlist vuota () disattiva la funzionalità ovunque, self consente solo la tua origine, un'origine specifica consente quell'origine, e * la consente ovunque. Ogni funzionalità ha anche una allowlist predefinita di *, self o nessuno che si applica quando non dici nulla.",{"question":260,"answer":261},"Come si comporta l'header Permissions-Policy con gli iframe incorporati?","Una funzionalità è disponibile all'interno di un iframe incorporato solo se sono soddisfatte due condizioni insieme: la tua pagina di primo livello deve consentire la funzionalità per l'origine di quel frame, e l'iframe stesso non deve averla disattivata. La pagina genitore fissa il confine esterno e nulla di incorporato può concedersi una funzionalità che la pagina genitore ha negato. L'attributo allow sull'elemento iframe funziona inoltre come eccezione per singola incorporazione: il frame può ricevere solo ciò che l'header già consente.",{"question":263,"answer":264},"Cosa succede se non imposti l'header Permissions-Policy?","Senza l'header, ogni funzionalità ricade sulla propria allowlist predefinita, più permissiva di quanto un sito tipico richieda per diverse funzionalità. Capacità che non usi mai restano raggiungibili, e il contenuto di terze parti incorporato può richiedere funzionalità che non avresti concesso. Raramente è urgente, ed è per questo che resta non affrontato, ma pesa di più dove incorpori codice che non hai scritto, come un tag di analytics, un widget di chat o un pixel di marketing, e gli scanner lo segnalano ora su quasi ogni sito che non lo ha impostato.",{"question":206,"answer":266},"Imposti Permissions-Policy come un singolo header di risposta HTTP, sul web server, nel livello applicativo o al margine. Una policy di partenza sensata disattiva le funzionalità che non usi e limita il resto alla tua origine, ad esempio geolocation=(), camera=(), microphone=(), payment=(). Testa prima con il compagno report-only, Permissions-Policy-Report-Only, che usa la Reporting API del browser per dirti cosa una policy bloccherebbe senza applicarla, così da consentire deliberatamente le funzionalità reali anziché romperle di sorpresa.",{"question":268,"answer":269},"Cosa cambia sul tuo sito una volta attivato l'header Permissions-Policy?","Per la maggior parte dei siti non cambia nulla di visibile, perché la policy interviene solo quando del codice tenta di raggiungere una funzionalità che non hai consentito. Il punto da controllare è qualsiasi funzionalità su cui il tuo sito fa affidamento e qualsiasi cosa serva alle tue terze parti incorporate, come un localizzatore di negozi con geolocation, una funzione video con camera e microfono, o un checkout con la payment API, che devono avere tutte le direttive impostate per consentire le origini giuste. Per questo il test in report-only conta prima dell'applicazione.",{"question":271,"answer":272},"Cosa dovresti fare adesso riguardo all'header Permissions-Policy?","Controlla se il tuo sito invia un header Permissions-Policy, perché senza di esso ogni funzionalità ricade sul suo valore predefinito. Se manca, aggiungilo in modalità report-only, elenca le funzionalità che usi davvero, conferma che nulla su cui fai affidamento venga bloccato, e poi applica una policy che disattiva tutto il resto.",{"question":274,"answer":275},"Cosa dovresti portare con te sull'header Permissions-Policy?","Permissions-Policy ti permette di disattivare le funzionalità del browser che il tuo sito non usa mai e di limitare quelle che usa alle sole origini che ne hanno bisogno, così che né i tuoi script né le terze parti incorporate possano raggiungere capacità che non hai mai voluto esporre. Il modo sicuro di adottarlo è testare in modalità report-only, confermare che le tue funzionalità reali funzionino ancora, e poi applicare una policy che disattiva il resto. Il passo più utile è controllare se il tuo sito invia l'header oggi, perché finché non lo fa, ogni funzionalità resta sul suo valore predefinito.",{},"\u002Fblog\u002Fit\u002Fwhat-is-permissions-policy","8 minuti",{"title":143,"description":253},"what-is-permissions-policy","blog\u002Fit\u002Fwhat-is-permissions-policy",[283,4,138,284],"Permissions-Policy","Privacy","-GUblmiUDb2gL-r9u42e0yNgyqyJgLs3S_LIgFhu0cI",1785141130843]