Rischi per la sicurezza dei browser: perché il browser è il nuovo endpoint

Il browser è il punto nevralgico in cui opera il vostro personale. È lì che i dipendenti effettuano l’autenticazione alle applicazioni SaaS, incollano i dati dei clienti negli strumenti di intelligenza artificiale, scaricano file sensibili, collaborano con partner esterni e accedono ai sistemi interni tramite SSO. Tuttavia, la maggior parte delle architetture di sicurezza continua a considerare il browser come una delle tante applicazioni presenti sull’endpoint, soggetta alle stesse politiche EDR generiche applicate a un lettore PDF o a un client di messaggistica. Questo divario tra il modo in cui il lavoro viene effettivamente svolto e il modo in cui viene applicata la sicurezza rappresenta oggi il principale punto cieco nella sicurezza aziendale.

I dati di intelligence sulle minacce del settore indicano che la stragrande maggioranza delle intrusioni avvenute nel 2024 era priva di malware, il che significa che si basava su credenziali legittime, flussi di identità affidabili e integrazioni approvate — attività che hanno origine nel browser e transitano attraverso di esso. Se la vostra strategia di sicurezza si limita all’agente sull’endpoint, state difendendo un perimetro che non corrisponde più alla superficie di attacco.

La violazione dei dati in 90 secondi: uno scenario che il vostro EDR non rileva mai

Immaginate un giovedì pomeriggio in una società di servizi finanziari di medie dimensioni. Un’analista senior apre Salesforce su Chrome per estrarre i dati trimestrali relativi al fatturato dei clienti in vista di una revisione interna. Copia una tabella contenente 200 record relativi ai clienti — nomi, valori dei contratti, date di rinnovo — e li incolla in ChatGPT, chiedendogli di redigere una sintesi per la sua riunione interfunzionale. Soddisfatta del risultato, scarica l’analisi generata dall’intelligenza artificiale in formato PDF e la salva sul proprio OneDrive personale, in modo da poterla esaminare sul proprio iPad durante il fine settimana.

Ogni fase si è svolta nell’ambito di un’unica sessione del browser. L’agente endpoint ha rilevato che Chrome effettuava richieste HTTPS. Il sistema DLP di rete ha rilevato traffico crittografato verso domini autorizzati. Nessun file è stato salvato sul disco locale fino al download finale del PDF — a quel punto i dati erano già sfuggiti al controllo dell’organizzazione in due direzioni: verso i server dello strumento di intelligenza artificiale e verso un account di archiviazione cloud personale.

Non si tratta di un caso isolato ipotetico. È la realtà quotidiana nelle organizzazioni in cui il lavoro basato sul browser ha superato i controlli di sicurezza basati sul browser. Gli autori di attacchi che sfruttano l’intelligenza artificiale hanno aumentato drasticamente le loro operazioni di anno in anno, e le intrusioni ora si diffondono attraverso identità affidabili, applicazioni SaaS e infrastrutture cloud. Quando il browser funge da intermediario in quasi ogni interazione con i dati e il vostro sistema di sicurezza non ha alcuna visibilità su ciò che accade all’interno della sessione del browser, state operando alla cieca.

Perché gli approcci tradizionali falliscono a livello di browser

La maggior parte delle infrastrutture di sicurezza aziendali è stata progettata per un contesto in cui le minacce si presentavano sotto forma di file, attraversavano la rete e raggiungevano gli endpoint. Tale architettura risultava efficace quando il lavoro veniva svolto tramite applicazioni installate localmente e i dati risiedevano su file server. Tre cambiamenti strutturali hanno reso obsoleto questo modello.

Gli agenti endpoint non possono accedere alle informazioni contenute nella sessione del browser

Gli strumenti EDR monitorano il comportamento dei processi, le operazioni di scrittura sui file e le chiamate di sistema. Essi considerano Chrome o Edge come un unico processo — non le 30 schede, le 5 applicazioni SaaS e le 3 estensioni del browser in esecuzione al suo interno. Quando un dipendente copia le informazioni personali identificative (PII) di un cliente da una scheda del CRM e le incolla in una scheda dell’assistente AI, l’agente dell’endpoint non rileva alcuna attività sospetta. Non vi è alcun file, nessun malware, nessun processo anomalo: si tratta semplicemente di un’operazione sugli appunti tra due contesti del browser.

Il DLP di rete perde visibilità a causa della crittografia e del SaaS

La crittografia TLS e il passaggio al modello SaaS comportano che i tradizionali dispositivi DLP di rete rilevino traffico crittografato diretto verso domini autorizzati. Essi non sono in grado di distinguere tra un dipendente che carica una presentazione di marketing approvata su SharePoint e un dipendente che carica un elenco di clienti su un account Dropbox personale: entrambe le operazioni appaiono come richieste POST HTTPS rivolte a servizi cloud riconosciuti. Il rapporto DBIR 2025 di Verizon ha confermato che le credenziali rubate hanno costituito il vettore di accesso iniziale nel 22% delle violazioni, e tali credenziali vengono quasi sempre inserite tramite un browser.

I firewall basati sulle categorie di URL non colgono le sfumature

I gateway web di sicurezza di vecchia generazione, che bloccano o consentono l’accesso a interi domini, non sono in grado di applicare i controlli granulari richiesti dai moderni flussi di lavoro dei browser. Bloccare ChatGPT in modo categorico allontana i team orientati alla produttività. Consentirne l’uso, invece, non offre alcun controllo sui dati che i dipendenti vi inseriscono. Il modello binario «consenti/blocca» — concepito per un’epoca in cui «non sicuro» significava «dominio notoriamente dannoso» — è strutturalmente incapace di regolare le modalità di utilizzo degli strumenti autorizzati. Comprendere le differenze tra i gateway web tradizionali e quelli di nuova generazione rappresenta il primo passo per colmare questa lacuna.

Cosa è cambiato: il browser è diventato il sistema operativo per il lavoro

La convergenza di tre tendenze ha trasformato il browser da un semplice motore di rendering nell’ambiente di lavoro principale dell’azienda — nonché nella sua superficie di attacco più esposta.

Il modello SaaS ha rivoluzionato lo stack applicativo

Cinque anni fa, le applicazioni fondamentali di un tipico lavoratore della conoscenza includevano client di posta elettronica installati localmente, suite per l’ufficio e strumenti specifici per il settore. Oggi, lo stesso lavoratore accede a Salesforce, Microsoft 365, Workday, ServiceNow, Slack e Jira esclusivamente tramite le schede del browser. Ogni evento di autenticazione, interazione con i dati e flusso di lavoro collaborativo passa attraverso il browser. Gli aggressori sfruttano la fiducia riposta nei sistemi di identità cloud, nelle integrazioni SaaS e nei flussi di autenticazione, avvalendosi di credenziali valide, provider di identità compromessi e token OAuth rubati. Secondo il Global Threat Report 2026 di CrowdStrike, tra gli attori delle minacce legati agli Stati, l’abuso di account validi ha rappresentato il 35% di tutti gli incidenti nel cloud.

GenAI ha aperto un nuovo canale di esfiltrazione

Quando un dipendente incolla codice sorgente proprietario, dati dei clienti o piani strategici in uno strumento GenAI, il browser funge da canale di trasmissione. Non vi è alcun trasferimento di file che il sistema DLP dell’endpoint possa ispezionare, né alcuna e-mail in uscita che il gateway di posta possa segnalare. I dati transitano attraverso un campo di testo del browser e, a meno che non si disponga di controlli a livello di sessione, si muovono senza alcun controllo di sicurezza. Man mano che l’IA viene integrata nelle piattaforme SaaS e nei flussi di lavoro operativi, gli autori degli attacchi hanno iniziato a sfruttare strumenti GenAI legittimi in decine di organizzazioni, inserendo prompt dannosi per sottrarre credenziali e dati.

L'accesso non gestito e il BYOD sono diventati una realtà permanente

La pandemia ha reso la norma l’uso di computer portatili dei collaboratori esterni, dispositivi personali e modelli di accesso “bring your own browser” che non sono mai stati coperti dagli agenti endpoint. Il rapporto DBIR 2025 di Verizon ha rilevato che il 46% dei dispositivi con credenziali aziendali presenti nei log degli infostealer non era gestito: un pericoloso divario tra il controllo aziendale e il comportamento degli utenti. Quando un collaboratore esterno apre il vostro tenant Salesforce nel proprio browser personale, il vostro agente EDR non è in esecuzione, il vostro DLP di rete non è attivo in linea e la vostra politica di categorizzazione degli URL non viene applicata. La sessione del browser è l’unico punto di controllo a vostra disposizione — e la maggior parte delle organizzazioni non dispone di alcuna misura di protezione in tale ambito.

Il manuale dell’avversario: come si concretizzano effettivamente i rischi legati ai browser

Per comprendere i rischi legati alla sicurezza dei browser è necessario mettere in relazione le tecniche specifiche degli autori degli attacchi con la sessione del browser. Due categorie prevalgono su tutte.

Furto di credenziali e dirottamento di sessione

Il browser è il più grande archivio di credenziali al mondo. Le password salvate, i cookie di sessione, i token OAuth e le asserzioni SSO risiedono tutti nel browser o transitano attraverso di esso. Il malware di tipo “infostealer” prende di mira specificatamente gli archivi di credenziali dei browser, raccogliendo le password salvate dai profili di Chrome, Edge e Firefox. Secondo il DBIR 2025 di Verizon, il coinvolgimento di terze parti nelle violazioni è raddoppiato, raggiungendo il 30% di tutti gli incidenti, spesso reso possibile dalle credenziali sottratte dalle sessioni del browser su dispositivi non gestiti. Si consideri il caso di un collaboratore esterno addetto al marketing presso un’azienda del settore sanitario che riutilizza la propria password SSO aziendale su un sito di shopping personale. Quel sito subisce una violazione, la password compare in un elenco combinato e un aggressore accede al portale SSO del collaboratore da un nodo di uscita VPN residenziale. L’intera catena ha inizio e fine nel browser.

Compromissione di tipo “drive-by” e sfruttamento delle vulnerabilità del browser

La tecnica MITRE ATT&CK T1189, denominata “Drive-by Compromise”, descrive il modo in cui gli aggressori possono ottenere l’accesso a un sistema tramite un utente che visita un sito web nel corso della normale navigazione. Non si tratta di un retaggio dell’era di Internet Explorer: sono stati osservati 41 gruppi di minaccia e famiglie di malware noti che utilizzano questa tecnica in ambiente reale. Gli aggressori sfruttano i meccanismi di notifica push del browser per inviare esche di phishing persistenti e reindirizzamenti dannosi che sopravvivono alla chiusura delle schede — poiché le notifiche push vengono concesse a livello di browser, non a livello di scheda. A differenza dei tradizionali exploit drive-by, questa tecnica si basa sull’ingegneria sociale volta a indurre l’utente a concedere le autorizzazioni alle notifiche, rendendola efficace anche contro browser completamente aggiornati

I moderni attacchi “watering hole” prendono di mira siti web specifici del settore: compromettono un portale fornitori che il vostro team di approvvigionamento visita quotidianamente, inseriscono codice JavaScript dannoso in una pagina di registrazione a una conferenza o diffondono pubblicità dannosa attraverso reti pubblicitarie legittime. Gartner sottolinea che le patch zero-day per Chromium possono richiedere dalle 24 alle 72 ore per essere distribuite nei browser aziendali full-stack: una finestra di vulnerabilità che gli aggressori sfruttano attivamente (Gartner, «Focus on Securing Browsers, Not Forcing a Secure Browser», ottobre 2025). La tecnologia di isolamento del browser esiste proprio per colmare questa lacuna, eseguendo i contenuti web in un ambiente isolato prima di visualizzarli all’utente.

Ingegneria sociale alla velocità del browser

Le operazioni di voice phishing (vishing) hanno registrato un’impennata drammatica nel 2024 e nel 2025; secondo quanto riportato da Cisco Talos, nel primo trimestre del 2025 il vishing ha rappresentato oltre il 60% di tutti gli interventi di risposta agli incidenti legati al phishing, diventando così il vettore di phishing più diffuso riscontrato dal loro team. Molte di queste campagne indirizzano le vittime verso pagine di raccolta delle credenziali basate sul browser — repliche perfette, pixel per pixel, delle schermate di accesso di Microsoft, Okta o Google. Come recentemente documentato da Google Threat Intelligence (Mandiant), l’autore dell’attacco chiama fingendo di essere il supporto IT, indirizza la vittima verso un portale SSO contraffatto e acquisisce sia la password che il token MFA in tempo reale mentre la vittima li digita. L’intera catena di attacco si svolge all’interno del browser e non lascia alcuna traccia di malware che l’agente dell’endpoint possa rilevare.

Cosa dovrebbero fare ora i team di sicurezza

Per colmare il divario relativo ai browser non è necessario smantellare l’infrastruttura di sicurezza esistente né imporre l’uso di un browser proprietario a cui i dipendenti opporrebbero resistenza. È invece necessario estendere i controlli di sicurezza collaudati — DLP, CASB, SWG, RBI e ZTNA — alla sessione del browser, dove i dati circolano effettivamente.

Applicare i controlli sui dati nel punto in cui avviene l'azione

Configurare criteri DLP che controllino le operazioni relative agli appunti, il caricamento e il download di file, nonché l’invio dei dati inseriti nei campi dei moduli all’interno delle sessioni del browser. Quando un dipendente copia un elenco di clienti da Salesforce e tenta di incollarlo in uno strumento di intelligenza artificiale non autorizzato, il criterio dovrebbe rilevare il modello di dati sensibili e bloccare l’operazione di incollaggio — non registrare l’evento tre giorni dopo. La piattaforma SSE Skyhigh Security applica questi controlli DLP in linea su applicazioni web, SaaS e private tramite un motore di policy unificato.

Isolare la navigazione ad alto rischio senza bloccarla

Non tutti i siti web sconosciuti devono necessariamente essere bloccati. Remote browser isolation visualizza i contenuti web all’interno di un container cloud protetto e trasmette una rappresentazione visiva al browser dell’utente. Se un analista degli acquisti deve visitare il portale di un fornitore che non conosce, l’RBI gli consente di navigare normalmente, garantendo al contempo che nessun codice dannoso raggiunga il suo endpoint. Questa è la risposta concreta al MITRE ATT&CK T1189: eliminare l’ambiente di esecuzione dell’exploit senza compromettere la capacità dell’utente di lavorare.

Applicare controlli a livello di sessione per i dispositivi non gestiti

Quando appaltatori, partner o dipendenti utilizzano dispositivi personali per accedere alle applicazioni SaaS aziendali, è necessario applicare controlli di sessione basati su reverse proxy o RBI che impediscano i download, blocchino il copia/incolla di contenuti sensibili e appongano filigrane alle schermate visualizzate — il tutto senza richiedere un agente sull’endpoint. Lo standard NIST SP 800-207 definisce il modello “zero trust” come una risposta alle tendenze delle reti aziendali, tra cui gli utenti remoti, il BYOD e le risorse basate sul cloud, concentrandosi sulla protezione delle risorse piuttosto che sui segmenti di rete. I controlli delle sessioni del browser costituiscono il punto di applicazione che rende operativo questo principio per l’accesso alle applicazioni SaaS.

Ottenere una visione d’insieme dell’IA “ombra” e dei servizi SaaS non autorizzati

Utilizzi una combinazione di CASB e SWG per individuare e classificare ogni strumento di intelligenza artificiale e servizio cloud a cui i dipendenti accedono tramite il browser. Applichi politiche basate sul rischio: consenta l’uso degli strumenti GenAI approvati con ispezione DLP, fornisca indicazioni agli utenti sui servizi a rischio medio e blocchi le destinazioni ad alto rischio. Senza questa visibilità, ogni scheda del browser rappresenta un potenziale canale di esfiltrazione.

Urgenza e definizione delle priorità: perché non si può rimandare

Gartner prevede che entro il 2028 il 25% delle organizzazioni potenzierà gli attuali strumenti di accesso remoto sicuro e di sicurezza degli endpoint implementando almeno una tecnologia di browser aziendale sicuro. Attualmente, meno del 10% ha adottato browser aziendali sicuri. Ciò significa che la stragrande maggioranza delle imprese utilizza la stessa architettura di sicurezza dei browser di tre anni fa, mentre la superficie di attacco si è notevolmente ampliata.

I calcoli sono semplici e sfavorevoli. Secondo il Rapporto Verizon 2025 sulle indagini relative alle violazioni dei dati (DBIR), l’uso improprio delle credenziali è stato il principale vettore di accesso iniziale alle violazioni: il 22% di tutte le violazioni confermate, con un dato sbalorditivo pari all’88% degli attacchi alle applicazioni web di base che hanno coinvolto credenziali rubate. Il browser è spesso il punto di partenza di tale accesso iniziale: attraverso una pagina di phishing, un flusso OAuth compromesso, un’estensione dannosa o un attacco di credential stuffing contro un accesso SaaS. Il DBIR ha inoltre documentato un’impennata dei metodi di aggiramento dell’autenticazione a più fattori (MFA), tra cui l’intercettazione di tipo «adversary-in-the-middle», il furto di token e il «prompt bombing», il che significa che nemmeno le organizzazioni che hanno implementato l’autenticazione a più fattori sono al riparo. Una volta che l’autore dell’attacco è in possesso di un token di sessione valido, si trova all’interno delle vostre applicazioni SaaS con lo stesso livello di accesso dei vostri dipendenti, e il vostro agente endpoint non ha nulla da segnalare.

Gartner rileva che i browser basati su Chromium rappresentano circa il 75% della quota di mercato totale dei browser (“Focus on Securing Browsers, Not Forcing a Secure Browser”, ottobre 2025), rendendo il browser un’unica superficie di attacco dominante, comune a quasi tutte le aziende. La questione non è se investire nella sicurezza dei browser. La questione è se farlo ora — finché c’è ancora tempo per implementare misure di controllo — oppure dopo che una violazione mediata da un browser vi costringerà ad agire.

Il Modello di maturità Zero Trust v2.0 della CISA fornisce un approccio per portare avanti gli sforzi di modernizzazione relativi al modello Zero Trust, strutturato attorno a cinque pilastri: identità, dispositivi, reti, applicazioni e carichi di lavoro, nonché dati. Il browser si colloca all’intersezione di tutti e cinque questi pilastri. È il dispositivo attraverso il quale viene autenticata l’identità, l’applicazione tramite la quale si accede ai dati e il percorso di rete attraverso il quale fluisce ogni transazione SaaS. Garantire la sicurezza della sessione del browser non è un progetto di nicchia, bensì un requisito fondamentale per la maturità dello Zero Trust.

Definizione di una strategia di sicurezza per i browser: da dove iniziare

I team di sicurezza non devono cercare di fare tutto e di più. È opportuno stabilire le priorità in base all’esposizione al rischio e alla fattibilità operativa.

Fase 1 — Visibilità (settimane 1–4). Attivare il rilevamento CASB e la registrazione SWG per identificare ogni applicazione SaaS, strumento di intelligenza artificiale e servizio cloud a cui si accede tramite i browser dei dipendenti. Quantificare l’utilizzo dello “shadow IT” e dello “shadow AI ”. Identificare quali tipi di dati sensibili transitano attraverso le sessioni del browser.

Fase 2 — Controlli in linea (mesi 2–3). Implementare le politiche DLP sul secure web gateway per ispezionare i caricamenti, i download, le operazioni di copia/incolla e l’invio dei moduli. Iniziate dai tipi di dati a più alto rischio: informazioni di identificazione personale (PII), documenti finanziari, codice sorgente e dati sanitari soggetti a normative.

Fase 3 — Isolamento e accesso non gestito (mesi 3–6). Attivare remote browser isolation le categorie web ad alto rischio, i domini non classificati e le sessioni SaaS su dispositivi non gestiti. Implementare controlli CASB tramite proxy inverso per l’accesso da parte di collaboratori esterni e tramite dispositivi BYOD alle applicazioni SaaS critiche.

Fase 4 — Applicazione continua (in corso). Integrare i dati di telemetria delle sessioni del browser con le vostre piattaforme SIEM e XDR. Correlare gli eventi relativi al browser — luoghi di accesso sospetti, modelli insoliti di accesso ai dati SaaS, utilizzo anomalo degli strumenti di intelligenza artificiale — con i segnali provenienti dagli endpoint e dalle identità, al fine di individuare le minacce trasversali ai domini.

Questo approccio graduale è in linea con quanto raccomandato dalla norma NIST SP 800-207 e dal Modello di maturità Zero Trust della CISA, che prevedono un percorso incrementale dalla maturità tradizionale a quella ottimale. Ciascuna fase riduce una superficie di rischio concreta, contribuendo al contempo a costruire un quadro di sicurezza completo per i browser.