Cookies et consentement
Les cookies que votre serveur pose sur un premier visiteur, avant tout bandeau, et ce que PostShip en dit.
Mis à jour le 11 septembre 2026
Sur cette page
- Ce que PostShip vérifie
- Les manques (le contrôle échoue)
- Les avertissements (le contrôle passe)
- Régler
- Ce qui déclenche une alerte
- Limites et plans
- Dépannage
- Pourquoi le contrôle passe-t-il alors que mon bandeau pose _ga au chargement ?
- Pourquoi mon cookie de session est-il signalé alors qu'il est HttpOnly ?
- Pourquoi « cookies_non_secure » n'apparaît-il pas sur mon site en http ?
Une requête sur la page d'accueil, sans aucun cookie envoyé : c'est exactement ce que reçoit quelqu'un qui arrive pour la première fois, avant tout bandeau, avant tout clic. Ce qui est déposé là l'est sans consentement — et c'est précisément ce que la CNIL sanctionne quand un _ga part avec la page. Ce contrôle lit les en-têtes Set-Cookie de cette première réponse, à chaque déploiement.
Ce que PostShip vérifie
Une seule requête GET, sans en-tête Cookie. Les cookies jugés sont ceux de la réponse finale, après redirections : c'est elle que le navigateur garde. Pas de navigateur : PostShip lit ce que le serveur envoie, pas ce que le JavaScript pose ensuite via document.cookie. Un _ga déposé côté client lui échappe — c'est la limite assumée de l'outil, et la raison pour laquelle le script de mesure chargé est au moins signalé.
Deux niveaux, tenus séparés. Les manques sont des faits lus dans Set-Cookie : ils font échouer le contrôle. Les avertissements sont des indices qui demandent un regard humain.
Les manques (le contrôle échoue)
| Code | Ce qui est lu |
|---|---|
traceurs_avant_consentement | Des cookies de mesure ou de publicité sont posés avant tout consentement. |
cookies_non_secure | Des cookies sont posés sans l'attribut Secure. Vérifié seulement sur une page https : un navigateur refuse même de poser Secure en clair. |
session_sans_httponly | Un cookie de session est lisible par JavaScript (pas de HttpOnly) : un vol de session à la première XSS. |
Les traceurs sont reconnus par leur nom, par préfixe et sans tenir compte de la casse : _ga, _gid, _gat, _gcl_, _fbp, _fbc, _hjid, _hjSession, _clck, _clsk, _uetsid, _uetvid, _pin_unauth, _tt_, _ttp, ajs_anonymous_id. Google Analytics 4 pose _ga_XXXXXXX à côté de _ga : le préfixe l'attrape sans connaître l'identifiant de propriété. IDE et NID (DoubleClick, Google) ne comptent que sur leur nom exact — trois lettres en préfixe attraperaient identifiant et tout ce qu'un développeur nomme librement.
Un cookie « ressemble à une session » quand son nom contient sess, session, sid, token, auth ou jwt. Les noms contenant csrf ou xsrf sont exclus à dessein : le motif « double soumission » exige que le script lise le jeton, et un jeton CSRF sans HttpOnly est la norme, pas une faute. Un traceur n'est jamais compté deux fois : _hjSession est reproché comme traceur, pas comme session exposée.
Les avertissements (le contrôle passe)
| Code | Ce qui est signalé |
|---|---|
samesite_absent | Des cookies n'ont pas d'attribut SameSite. Chrome applique Lax par défaut, pas tous les navigateurs. |
scripts_traceurs_charges | Un script de mesure tiers est chargé sur la page : googletagmanager.com, google-analytics.com, connect.facebook.net, static.hotjar.com, clarity.ms, cdn.segment.com (et leurs sous-domaines). |
Chaque cookie lu est dans le détail du contrôle (30 au plus) : nom, Secure, HttpOnly, SameSite, durée en jours (depuis Max-Age, qui l'emporte sur Expires, comme le fait un navigateur), domaine. Zéro cookie est un pass parfaitement normal : un site statique n'en pose aucun, c'est même la situation la plus saine.
Régler
Rien à configurer : la cible est créée par PostShip pour chaque projet, sur l'URL de base, hors quota d'URLs. Projet → Santé → Contrôles du site → Cookies pour lire le verdict et la liste des cookies. Le contrôle se désactive depuis la même carte.
Il tourne au déploiement, comme les autres contrôles du site : les cookies qu'un serveur pose ne changent qu'au déploiement.
Ce qui déclenche une alerte
Un fail (au moins un manque), après le nombre de confirmations de vos règles. L'alerte porte la phrase du code, par exemple « Des cookies de mesure ou de publicité sont posés avant tout consentement. » Les avertissements se lisent dans l'app et ne sonnent pas.
Pas de réponse : error, pas fail. Une coupure réseau n'est pas un défaut de conformité.
Un échec compte dans le Ship Score, catégorie « hygiène du site ».
Limites et plans
| Free | Pro | Team | |
|---|---|---|---|
| Verdict et liste des cookies | Oui | Oui | Oui |
| Alerte sur un manque | Non | Oui | Oui |
Voir les plans.
Dépannage
Pourquoi le contrôle passe-t-il alors que mon bandeau pose _ga au chargement ?
Parce que le cookie est posé par le JavaScript, pas par votre serveur. PostShip ne lit que Set-Cookie. Si le script de mesure est chargé, l'avertissement scripts_traceurs_charges vous le dit : c'est le signal pour vérifier vous-même.
Pourquoi mon cookie de session est-il signalé alors qu'il est HttpOnly ?
Vérifiez qu'il est posé par la réponse finale et non par une redirection intermédiaire : PostShip ne voit que la dernière réponse. Vérifiez aussi la casse et l'orthographe de l'attribut — HttpOnly est lu sans tenir compte de la casse, mais Http-Only n'existe pas.
Pourquoi « cookies_non_secure » n'apparaît-il pas sur mon site en http ?
Secure n'a de sens que sur une page chiffrée. Exiger l'attribut sur une page http serait reprocher un défaut impossible à corriger. Passez en https d'abord ; le contrôle des redirections vous y aide.