Vérificateur de cookies

Non, et rien sur le web ne peut l'être. Une page n'a le droit de lire que les cookies appartenant à sa propre adresse — cette restriction est toute la raison pour laquelle les cookies sont sûrs, sans quoi n'importe quel site pourrait lire ceux de votre banque. Pour voir les cookies que votre navigateur détient déjà, il faut ses propres réglages ou ses outils de développement, ou une extension à qui vous avez donné cette permission. Ceci visualise ce qu'un site renvoie, ce qui est une autre question et celle à laquelle on peut répondre d'ici.

Parce qu'il demande une page, une fois, en visiteur qui n'y est jamais allé. Beaucoup de cookies sont déposés plus tard — par JavaScript après le chargement, par un script tiers, ou seulement quand quelqu'un accepte un bandeau de consentement. Rien de tout cela n'apparaît dans une première réponse. Voyez ce que vous avez ici comme les cookies qu'un site dépose avant que vous ayez accepté quoi que ce soit, chiffre intéressant pour une revue de confidentialité, pas comme le total.

Demandez-lui une page et lisez ce qu'il renvoie, ce que fait exactement ceci — entrez une adresse pour vérifier les cookies de pages web que vous ne contrôlez pas, et vous obtenez chaque cookie de cette première réponse avec son domaine, son expiration et ses marqueurs. C'est ce que fait un navigateur avant d'afficher quoi que ce soit, moins l'affichage. Ce qu'il ne montrera pas, c'est ce qui est déposé ensuite par JavaScript ou après un bandeau de consentement : voyez-le comme ce qu'un site dépose avant votre accord, et non comme la liste complète.

Secure empêche l'envoi du cookie en HTTP clair, pour qu'il ne soit pas lisible par qui surveille la connexion. HttpOnly le cache à JavaScript, pour qu'une faille de script inter-sites ne puisse pas le voler — c'est celui qui compte le plus pour un cookie de connexion. SameSite règle si le cookie accompagne les requêtes lancées par d'autres sites : Strict jamais, Lax seulement pour les clics de lien ordinaires, None toujours, ce qui exige alors Secure. L'absence de SameSite est traitée comme Lax par les navigateurs actuels, mais l'écrire vaut mieux que se fier à une valeur par défaut qui a déjà changé.

Non. Un cookie que JavaScript doit lire — une préférence de thème, un bandeau écarté, une langue — doit être lisible par JavaScript, donc HttpOnly le casserait. Le marqueur compte pour tout ce qui vous identifie : un identifiant de session, un jeton de connexion, un panier lié à un compte. Cet outil dit quels marqueurs manquent et contre quoi chacun protège ; savoir si cela compte dépend de l'usage du cookie, et seul le site le sait.

Il voit une requête de page ordinaire venant de notre serveur, pas de vous. Votre adresse n'est pas transmise et aucun cookie n'est stocké, envoyé ni réutilisé — la réponse est lue une fois puis jetée. Si vous collez un en-tête Set-Cookie au lieu d'une adresse, rien n'est demandé du tout et toute la vérification se fait sans quitter cette page.

Tout ce qui n'est pas une adresse web publique ordinaire : des noms locaux comme localhost, des adresses de réseaux privés, et tout ce qui n'est ni http ni https. Un outil qui va chercher ce qu'on lui donne peut être pointé vers des machines que seul notre serveur atteint, donc celles-là sont refusées d'emblée et il le dit, y compris quand une redirection tente de l'emmener quelque part de privé.

C'est l'affaire de votre navigateur, pas d'une page — aucun site ne peut effacer les cookies d'un autre. Dans Chrome et Edge : Paramètres, Confidentialité et sécurité, Cookies tiers, puis Voir toutes les données et autorisations des sites ; dans Firefox : Paramètres, Vie privée et sécurité, Cookies et données de sites, Gérer les données ; dans Safari : Réglages, Confidentialité, Gérer les données de sites web. Tous permettent de retirer un site plutôt que tout, ce qui est en général ce qu'on veut — tout effacer vous déconnecte partout.