Cookie di prima parte ricevuto al primo contatto.
Secure e HttpOnly non risultavano impostati.
Quando apriamo una pagina di registrazione vediamo un modulo, alcuni campi da compilare e un pulsante per creare l'account. Quello che non vediamo è lo scambio di informazioni che avviene nello stesso momento tra il browser e il server.
È proprio da una pagina di registrazione per un evento tecnologico internazionale che è iniziata questa storia. Il servizio era ospitato su una piattaforma B2B molto diffusa. Al primo accesso, prima ancora di compilare il modulo, il server ha rilasciato un cookie identificativo destinato a restare nel browser fino al 10 settembre 2027.
Il nome della piattaforma non è importante. Lo è invece ciò che quel controllo ha reso visibile.
Un identificativo persistente al primo contatto
Il cookie rilevato era di prima parte, aveva scadenza nel settembre 2027 e utilizzava SameSite Lax. Mancavano invece Secure e HttpOnly, due attributi che svolgono un ruolo preciso nella protezione dei cookie.
Secure limita la trasmissione alle connessioni cifrate. HttpOnly impedisce agli script della pagina di leggere direttamente il contenuto del cookie attraverso il browser. La loro assenza non significa che sia avvenuto un attacco, ma significa che quelle due protezioni non erano attive.
Il controllo non ha trovato cookie di terza parte o riferimenti a servizi conosciuti di marketing, analisi e profilazione nella risposta HTTP e nell'HTML statico iniziali. È un risultato utile, anche se una pagina moderna può caricare altri elementi in seguito attraverso JavaScript.
La domanda lasciata dal report
Per quale motivo un visitatore riceve un identificativo che dura un anno ancora prima di creare il proprio account?
La durata non basta per conoscere la funzione del cookie. Può avere una finalità tecnica oppure essere collegato ad altre attività. Per capirlo occorre confrontare il comportamento osservato con l'informativa e con le spiegazioni del fornitore.
Non sappiamo, sulla base di questi soli dati, quale sia la finalità del cookie. Sappiamo però che il cookie era presente e possiamo documentarne le caratteristiche.
Vedere quello che normalmente resta nascosto
Da questa esigenza è nato Cookie Tracker, lo strumento open source sviluppato da MCProjectLab per rendere leggibile ciò che accade durante il primo contatto con un sito.
Cookie Tracker visita la pagina indicata, raccoglie i cookie ricevuti e ne mostra dominio, durata e principali attributi di sicurezza. Esamina anche gli script presenti nel codice iniziale e segnala eventuali riferimenti a servizi noti di analisi, pubblicità, gestione dei tag e registrazione delle sessioni.
Cookie Tracker analizza la risposta HTTP e l'HTML statico iniziale senza eseguire JavaScript.
Il risultato può essere salvato in JSON o CSV e conservato come prova tecnica. Il valore dell'identificativo viene escluso dal report, perché per documentare le caratteristiche di un cookie non è necessario archiviarne il contenuto.
Il tool non si ferma alla formula generica “questo sito usa cookie”. Mostra quali cookie ha realmente ricevuto, quanto durano e quali protezioni risultano attive.
Cookie Tracker
Controllo open source dei cookie HTTP, degli attributi di sicurezza e dei riferimenti a tracker.
Dalla percezione alla prova
Informative e banner sono necessari, ma raccontano ciò che un servizio dichiara. Un audit osserva ciò che il sistema fa davvero. Solo mettendo insieme questi due livelli si può iniziare una valutazione seria.
Cookie Tracker non emette sentenze legali e non pretende di sostituire un'analisi completa nel browser. Il suo ruolo è più concreto. Trasforma uno scambio invisibile in dati che possono essere letti, confrontati e discussi.
Nel caso esaminato ha documentato un identificativo con scadenza al 10 settembre 2027 senza Secure e HttpOnly. Un rilievo semplice, ma sufficiente per porre domande precise sulla durata, sulla funzione e sulle protezioni scelte.
Ed è proprio questa differenza tra supporre e misurare che ha dato origine a Cookie Tracker.
La trasparenza digitale comincia qui, quando ciò che accade dietro una pagina smette di essere invisibile e diventa verificabile.
Fonti
RFC 6265 HTTP State Management Mechanism, sezioni dedicate a Secure e HttpOnly.
IETF draft-ietf-httpbis-rfc6265bis-22, sezione dedicata a SameSite. Fonti consultate l'11 settembre 2026.