La plupart des navigateurs supportent les cookies et permettent à l'utilisateur de les désactiver. Les options les plus courantes sont les suivantes:
La plupart des navigateurs permettent aussi une suppression totale des données personnelles incluant les cookies. Des modules complémentaires pour contrôler les permissions des cookies existent aussi.
Depuis leur introduction sur Internet, de fausses idées sur les cookies ont circulé sur Internet et dans les médias. En 1998, CIAC, une équipe de surveillance des incidents d'ordinateur du Département de l'énergie des États-Unis, a déterminé que les failles de sécurité des cookies étaient « essentiellement non existantes » et a expliqué que « l'information sur la provenance de vos visites et le détail des pages web que vous avez visitées existe déjà dans les fichiers de journalisation des serveurs web ». En 2005, Jupiter Research a publié les résultats d'une étude, dans laquelle un pourcentage important d'interrogés a cru véridiques certaines des fausses affirmations suivantes:
Les cookies ne peuvent pas effacer ou lire l'information provenant de l'ordinateur de l'utilisateur. Cependant, les cookies permettent de détecter les pages web visitées par un utilisateur sur un site donné ou un ensemble de sites. Ces informations peuvent être collectées dans un profil d'utilisateur. Certains profils sont anonymes, en ce sens qu'ils ne contiennent pas d'information personnelle, pourtant même de tels profils peuvent être controversés.
Selon la même étude, un grand pourcentage d'utilisateurs d'Internet ne savent pas comment supprimer les cookies. L'une des raisons pour laquelle les gens ne font pas confiance aux cookies est parce que certains sites ont abusé de l'aspect de l'identification personnelle des cookies et ont partagés ces informations avec d'autres sources. Un grand pourcentage de la publicité ciblée provient de l'information glanée par les cookies de pistage.
En plus des problèmes d'atteinte à la vie privée, les cookies ont aussi quelques désavantages techniques. En particulier, ils n'identifient pas toujours exactement les utilisateurs, ils peuvent être utilisés pour des attaques de sécurité, et ils sont en oppositions avec le Representational State Transfer (Transfert représentatif d'état, REST) style architectural du logiciel.
Si plus d'un navigateur est utilisé sur un ordinateur, dans chacun d'eux il y a toujours une unité de stockage séparé pour les cookies. Par conséquent les cookies n'identifient pas une personne, mais une combinaison de compte d'utilisateur, un ordinateur, et un navigateur Web. Ainsi, n'importe qui peut utiliser ces comptes, les ordinateurs, ou les navigateurs qui ont la panoplie des cookies.
De même, les cookies ne font pas la différence entre les multiples utilisateurs qui partagent le même compte d'utilisateur, l'ordinateur, et le navigateur.
Durant l'opération normale, les cookies sont renvoyés entre le serveur (ou un groupe de serveurs dans le même domaine) et le navigateur de l'ordinateur de l'utilisateur. Depuis que les cookies peuvent contenir des information sensibles (nom de l'utilisateur, un mot de passe utilisé pour une authentification, etc.), leurs valeurs ne devraient pas être accessibles aux autres ordinateurs. Le vol de cookie est un acte d'interception des cookies par un tiers non autorisé.
Les cookies peuvent être volés via un renifleur de paquet dans une attaque appelée détournement de session. Le trafic sur le net peut être intercepté et lu par les ordinateurs autres que ceux qui envoient et qui reçoivent (particulièrement sur l'espace public Wi-fi non-crypté). Ce trafic inclus les cookies envoyés sur des sessions ordinaires http non-crypté. Quand le trafic réseau n'est pas crypté, des utilisateurs malveillants peuvent ainsi lire les communications d'autres utilisateurs sur le réseau, en utilisant ce qu'on appelle les renifleurs de paquets.
Ce problème peut être surmonté en sécurisant la communication entre l'ordinateur de l'utilisateur et le serveur en employant la Couche Sécurisée de Transport (protocole https) pour encrypter la connexion. Un serveur peut spécifier un drapeau sécurisé tout en mettant en place un cookie; le navigateur l'enverra seulement sur une ligne sécurisée, comme une connexion en SSL.
Cependant beaucoup de sites, bien qu'utilisant une communication encryptée https pour l'authentification de l'utilisateur (c'est à dire la page de connexion), envoient ultérieurement des cookies de session et d'autres données normalement, par des connexions http non-cryptées pour des raisons d'efficacité. Les attaquants peuvent ainsi intercepter les cookies d'autres utilisateurs et en se faisant passer pour eux sur des sites appropriés ou en les utilisant dans des attaques de cookies.
Un autre moyen pour voler les cookies est l'écriture de script dans les sites et faire en sorte que le navigateur envoie lui-même les cookies à des serveurs malveillants qui ne les reçoivent jamais. Les navigateurs modernes permettent l'exécution de parties de code recherchées à partir du serveur. Si les cookies sont accessibles pendant l'exécution, leurs valeurs peuvent être communiquées sous une certaine forme aux serveurs qui ne devraient pas y accéder. Encrypter les cookies avant leur envoi sur le réseau n'aide pas à contrer l'attaque.
Ce type d'écriture de script dans le site est typiquement employé par les attaquants sur les sites qui permettent aux utilisateurs de poster des contenus HTML. En intégrant une partie de code compatible dans le poste en HTML, un attaquant peut recevoir des cookies d'autres utilisateurs. La connaissance de ces cookies peut être utilisée en se connectant au même site en utilisant les cookies volés, ainsi en étant reconnu en tant qu'utilisateur dont les cookies ont été volés.
Un moyen pour prévenir de telles attaques est d'utiliser le drapeau HttpOnly; c'est une option, introduite depuis la version 6 de Internet Explorer de Microsoft en PHP depuis la version 5.2.0 qui est prévue pour rendre le cookie inaccessible au client proche du script. Cependant, les développeurs web devraient prendre en compte dans leur développement de site afin qu'ils soient immunisés par l'écriture de script dans le site.
Une autre menace de sécurité utilisée est la Fabrication de Demande dans le site.
La spécification technique officielle permet aux cookies d'être renvoyés uniquement aux serveurs du domaine dont ils sont originaires. Cependant, la valeur des cookies peut être envoyée à d'autres serveurs en utilisant des moyens différents des en-têtes de cookies.
En particulier, les langages de script comme JavaScript et JScript sont généralement autorisés à accéder aux valeurs des cookies et sont capables d'envoyer des valeurs arbitraires à n'importe quel serveur sur Internet. Cette capacité des scripts est utilisée à partir de sites Web permettant aux utilisateurs de poster des contenus HTML que d'autres utilisateurs peuvent voir.
Par exemple, un attaquant fonctionnant sur le domaine exemple.com peut publier un commentaire contenant le lien suivant pointant vers un blog populaire qu'il ne contrôle pas autrement:
Quand un autre utilisateur clique sur ce lien, le navigateur exécute la partie de code de l'attribut onclick, ainsi il remplace la chaîne de caractère document.cookie par la liste des cookies de l'utilisateur qui sont actifs pour cette page. Par conséquent, cette liste de cookies est envoyée au serveur exemple.com, et l'attaquant est donc capable de collecter les cookies de cet utilisateur.
Ce type d'attaque est difficile à détecter du coté utilisateur parce que le script provient du même domaine qui a mis en place le cookie, et l'opération d'envoi des valeurs semble être autorisée par ce domaine. Il est considéré que c'est la responsabilité des administrateurs opérant ce type de sites de mettre en place des restrictions empêchant la publication de code malveillant.
Les cookies ne sont pas directement visibles aux programmes du coté client comme le JavaScript s'ils ont été envoyés avec le drapeau HttpOnly. Du point de vu du serveur, la seule différence est que dans la ligne de l'en-tête set-cookie y est ajouté un nouveau champ contenant la chaîne de caractères 'HttpOnly':
Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/; domain=.exemple.net; HttpOnly
Quand le navigateur reçoit un tel cookie, il est sensé l'utiliser normalement dans l'échange HTTP suivant, mais sans le rendre visible aux scripts exécutés du côté client. Le drapeau 'HttpOnly' ne fait partie d'aucune spécification technique officielle, et n'est pas implémenté dans tous les navigateurs. Notez qu'il n'y a actuellement aucun moyen de prévenir la lecture et l'écriture des cookies de session par la méthode XMLHTTPRequest.
Dès que les cookies ont besoins d'être stockés et renvoyés inchangés au serveur, un attaquant peut modifier la valeur des cookies avant leur renvoi au serveur. Si, par exemple, un cookie contient la valeur totale que l'utilisateur doit payer pour les articles mis dans le panier du magasin, en changeant cette valeur le serveur est exposé au risque de faire payer moins l'attaquant que le prix de départ. Le procédé de trifouiller la valeur des cookies est appelé empoisonnement de cookie est utilisé après un vol de cookie pour rendre l'attaque persistante.
La plus part des sites web, cependant, stocke seulement un identifiant de session - un numéro unique généré aléatoirement utilisé pour identifier l'utilisateur de la session - dans le cookie lui-même, alors que toute le reste de l'information est stocké sur le serveur. Dans ce cas, le problème de l'empoisonnement de cookie est largement éliminé.
Chaque site est supposé avoir ses propres cookies, donc un site comme exemple.com ne devrait pas être capable de modifier ou créer des cookies sur un autre site, comme exemple.org. Les vulnérabilités du remplacement de cookie dans un navigateur web permettent à des sites malveillants d'enfreindre cette règle. C'est similaire à l'empoisonnement de cookie, mais l'attaquant exploite des utilisateurs utilisant des navigateurs vulnérables, au lieu d'attaquer directement le site. Le but de telles attaques peut être le vol de l'identifiant de session.
Les utilisateurs devraient utiliser les versions les plus récentes des navigateurs Web dans lesquels ces vulnérabilités sont pratiquement éliminées.
L'utilisation des cookies peut générer une contradiction entre l'état du client et l'état stocké dans le cookie. Si l'utilisateur acquiert un cookie et clique sur le bouton « Retour » du navigateur, l'état du navigateur n'est généralement pas le même qu'avant cette acquisition. Par exemple, si le panier d'une boutique en ligne est réalisé en utilisant les cookies, le contenu du panier ne peut pas changer quand l'utilisateur revient dans l'historique du navigateur: si l'utilisateur presse sur un bouton pour ajouter un article dans son panier et clique sur le bouton « Retour », l'article reste dans celui-ci. Cela n'est peut être pas l'intention de l'utilisateur, qui veut certainement annuler l'ajout de l'article. Cela peut mener à un manque de fiabilité, de la confusion, et des bugs. Les développeurs Web doivent donc être conscients de ce problème et mettre en œuvre des mesures visant à gérer des situations comme celle-ci.
Les cookies permanents ont été critiqués par les experts de la sécurité de la vie privée pour ne pas être prévus pour expirer assez tôt, et de ce fait permettre aux sites web de suivre les utilisateurs et de construire au fur et à mesure leur profil. Cet aspect des cookies fait partie aussi du problème de détournement de session, parce que un cookie permanent volé peut être utilisé pour se faire passer pour un utilisateur pour une période de temps considérable.