A partire da metà ottobre 2026, Microsoft Entra ID inizierà a bloccare gli script di terze parti iniettati nelle pagine di accesso ospitate su login.microsoftonline.com. La modifica, annunciata tramite il Microsoft 365 Message Center (riferimento MC1481309), introduce una Content Security Policy (CSP) che limita l’esecuzione di codice JavaScript ai soli domini CDN approvati da Microsoft, chiudendo di fatto una superficie di attacco che negli ultimi anni è stata sfruttata per campagne di cross-site scripting (XSS) contro i flussi di autenticazione aziendale.

Per chi amministra ambienti Microsoft 365 e Azure, questa non è una modifica da ignorare: se la vostra organizzazione utilizza estensioni browser, strumenti di monitoraggio dell’autenticazione o soluzioni di personalizzazione del branding che iniettano codice nella pagina di login, è il momento di fare un inventario e testare prima che il blocco diventi effettivo.

Cosa cambia esattamente

Oggi alcune soluzioni di sicurezza, monitoraggio e personalizzazione aggiungono funzionalità alla pagina di accesso di Entra ID iniettando script direttamente nel DOM della pagina ospitata da Microsoft. È una pratica comune per strumenti che vogliono, ad esempio, raccogliere metriche aggiuntive sul comportamento dell’utente durante il login, aggiungere elementi di branding personalizzato oltre a quanto consentito dalle opzioni native di Entra ID, oppure integrare controlli di sicurezza di terze parti nel flusso di autenticazione.

Il problema è che l’iniezione di script, per quanto utile, amplia la superficie d’attacco della pagina più critica di tutte: quella dove gli utenti inseriscono le proprie credenziali. Un header CSP mal configurato, un’estensione compromessa o una libreria di terze parti vulnerabile possono trasformarsi in un vettore per attacchi XSS mirati a sottrarre credenziali o token di sessione.

Con questa modifica, Microsoft aggiunge un header CSP alle pagine di sign-in che consente l’esecuzione solo di script provenienti da domini CDN Microsoft attendibili. Qualsiasi script esterno iniettato da estensioni browser o strumenti di terze parti smetterà di funzionare.

Tempistiche del rollout

Secondo l’annuncio nel Message Center, il rollout è pianificato nel seguente modo:

• Inizio: metà ottobre 2026;
• Completamento: fine ottobre 2026;
• Scadenza consigliata per le verifiche: 19 ottobre 2026.

Un dettaglio importante: la modifica è abilitata di default come parte dell’aggiornamento del servizio e non richiede alcuna configurazione da parte del tenant. Non esiste quindi un interruttore per ritardare l’attivazione: l’unica strategia possibile è prepararsi in anticipo, non rimandare la verifica a dopo il rollout.

Chi è interessato (e chi no)

Il blocco si applica esclusivamente alle esperienze di accesso basate su browser che transitano da login.microsoftonline.com. Rientrano nel perimetro le organizzazioni che:

• autenticano gli utenti tramite il flusso web standard su login.microsoftonline.com;
• hanno distribuito estensioni browser o strumenti che iniettano script nella pagina di login per finalità di monitoraggio, sicurezza o personalizzazione.

Restano invece esclusi dall’impatto:

• i tenant Microsoft Entra External ID, non toccati da questa modifica;
• le applicazioni che si autenticano tramite MSAL (Microsoft Authentication Library) o tramite flussi basati su API, dato che la CSP si applica solo alle interfacce web renderizzate nel browser.

In altre parole: il normale login da browser continuerà a funzionare per tutti gli utenti, anche per quelli le cui organizzazioni usano strumenti che verranno bloccati. Semplicemente, quegli strumenti aggiuntivi smetteranno di funzionare o genereranno errori silenziosi, senza impedire l’accesso.

Cosa deve fare un amministratore prima di ottobre

Se la vostra organizzazione non utilizza strumenti che iniettano script nelle pagine di login, non è richiesta alcuna azione. Per tutti gli altri, il percorso di preparazione dovrebbe includere questi passaggi:

1. Censire gli strumenti in uso. Verificate quali estensioni browser aziendali, soluzioni SIEM/SOAR o prodotti di customer identity management iniettano codice nelle pagine di sign-in Entra ID. Spesso questi strumenti sono stati distribuiti anni fa da team diversi (sicurezza, UX, help desk) e la conoscenza del “perché sono lì” si è persa nel tempo.
2. Testare in un ambiente pilota. Create un tenant di test o isolate un gruppo di utenti pilota per verificare l’impatto reale prima che il blocco diventi globale a metà ottobre.
3. Identificare alternative supportate. Per esigenze di branding personalizzato, Entra ID offre opzioni native (Company Branding) che non richiedono iniezione di script e che continueranno a funzionare regolarmente. Per esigenze di monitoraggio, valutate soluzioni basate su log di sign-in e Microsoft Graph API invece che su script lato client.
4. Aggiornare la documentazione e informare l’help desk. Se uno strumento di monitoraggio smette improvvisamente di raccogliere dati dopo metà ottobre, il team di supporto deve sapere che la causa è questa modifica pianificata e non un guasto imprevisto.
5. Verificare i fornitori terzi. Se usate prodotti di sicurezza o identity verification di terze parti che si integrano con la pagina di login Entra ID, contattate il vendor per sapere se e come stanno adattando il proprio prodotto alla nuova CSP.

Perché questa modifica ha senso dal punto di vista della sicurezza

Le pagine di autenticazione sono per definizione l’obiettivo più ambito dagli attaccanti: chi riesce a eseguire codice arbitrario in quel contesto può potenzialmente intercettare credenziali, manipolare il DOM per ingannare l’utente, o dirottare token di sessione prima ancora che l’utente completi l’MFA. Irrigidire la CSP su un dominio ad altissimo valore come login.microsoftonline.com è una misura coerente con la direzione che Microsoft ha preso negli ultimi mesi su hardening dell’identità (si pensi anche agli interventi recenti su Conditional Access e sul monitoraggio dei token refresh).

Per i sistemisti, questo caso è anche un promemoria generale: qualsiasi integrazione che si basa sull’iniezione di script in pagine di terze parti — specialmente pagine di login — va considerata intrinsecamente fragile, perché può essere disabilitata da un giorno all’altro con un aggiornamento lato fornitore, senza preavviso configurabile. Dove possibile, è preferibile orientarsi verso integrazioni ufficiali basate su API (Microsoft Graph, webhook, log di audit) piuttosto che su meccanismi non supportati.

Conclusione

Il blocco dello script injection su Entra ID è una modifica di sicurezza silenziosa ma potenzialmente dirompente per chi non si prepara: non blocca l’accesso degli utenti, ma può interrompere strumenti di monitoraggio o personalizzazione distribuiti da tempo senza che nessuno se ne accorga fino a quando smettono di funzionare. L’azione concreta da fare questa settimana è una sola: verificare con il proprio team di identity management se esistono integrazioni basate su script injection nella pagina di login, e pianificare un test prima della finestra di rollout di metà ottobre 2026.

Fonte: Petri IT Knowledgebase e Microsoft 365 Message Center (MC1481309)